Multi-line -c flag doesn't work on Windows

[evhub]

Simplest reproduction seems to be

mypy -c '
a = 5  # type: str'

which does not produce any errors, despite the fact that a is clearly incorrectly typed. The similar

mypy -c 'a = 5  # type: str'

however, does show an error, which seems to indicate that the first behavior is definitely a bug.

[ddfisher]

Strange, that's not the case for me:

$ python3 -m mypy -c '
a = 5  # type: str'
<string>:2: error: Incompatible types in assignment (expression has type "int", variable has type "str")

[evhub]

@ddfisher Strange. I'm running mypy 0.4.5 on Python 3.5.1 and Windows 10. My console log is:

C:\Users\Evan\Documents\GitHub> mypy -c '
>> a = 5  # type: str'
>>
C:\Users\Evan\Documents\GitHub> mypy -c 'a = 5  # type: str'
<string>:1: error: Incompatible types in assignment (expression has type "int", variable has type "str")

[ddfisher]

Hmm. Mine is on mypy 0.4.5; Python 3.5.2; OS X 10.11. Is it possible your terminal is removing the comment?

Maybe try:

echo '
a = 5  # type: str'

and

mypy -c '
a = "foo" 
a = 5'

[gvanrossum]

@evhub If you can put a print() statement in mypy to confirm the string argument it is receiving that might shed light on the matter. It is likely some odd interaction with the Windows shell. I wonder if there's a CRLF vs. LF issue? E.g.

diff --git a/mypy/main.py b/mypy/main.py
index bbc3002..8a87e05 100644
--- a/mypy/main.py
+++ b/mypy/main.py
@@ -314,6 +314,7 @@ def process_options(args: List[str],
             fail("Can't find package '{}'".format(special_opts.package))
         return targets, options
     elif special_opts.command:
+        print(repr(special_opts.command))
         options.build_type = BuildType.PROGRAM_TEXT
         return [BuildSource(None, None, '\n'.join(special_opts.command))], options

[evhub]

@ddfisher The echo output includes the comment, so I don't think that's the issue.
@gvanrossum A CRLF vs. LF issue seems plausible, especially since I just tried it on the Ubuntu subsystem for Windows and it worked just fine. Adding your print statement shows that MyPy seems to only be receiving the first line, which is consistent with the behavior I'm experiencing:

C:\Users\Evan\Documents\GitHub> mypy -c '#first line
>> a = 5  # type: str'
>>
['#first line']

[gvanrossum]

Have a look at mypy.bat: https://github.com/python/mypy/blob/master/scripts/mypy.bat I suspect the bug is there. Thanks for including the output from that print() statement!

[evhub]

@gvanrossum Did a little bit of research, and it looks like this is just an inherit issue with cmd.exe. I couldn't replicate this in any of my own installed Python scripts, though, so I looked around a bit and it seems that setuptools provides a way to get around this by setting console_scripts in entry_points, but since MyPy installs itself by setting scripts directly, it doesn't work.

[gvanrossum]

See also #1226.

As a work around you can use multiple -c flags: mypy -c '' -c 'a = 5 # type: str'.

[evhub]

@gvanrossum Great, thanks! It seems like calling python -m mypy instead of calling mypy directly also works, and then there's no need for multiple -c invocations.

[emmatyping]

I believe this is fixed, as we now use console_scripts to install mypy, meaning we aren't hit by the batch file issue.