<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 18, 2015 at 7:28 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span>Um, what did you mean by "run-time of compile time static typing"? I'm guessing "or" instead of "of". With that assumption, I think the answer is both.<br></div></div></div></blockquote><div><br></div><div>sorry for the typo -- yes that was supposed to be "or" <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I want annotations to be (eventually) reserved for a standard type notation. The PEP focuses on the notation. The (by far largest) use case I see for the notation is running a separate off-line type checker, which acts like a linter but with much more understanding of types. (But not perfect!) A second use case (for the same notation!) is equally off-line, to provide information an IDE needs so it can give accurate suggestions etc.<br></div></div></div></div></blockquote><div><br></div><div>both good things, yes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Some use cases that people (including myself) have often assumed but which I now find mostly anti-ideas: efficient code generation; run-time type checking; exact type checking by the Python interpreter when it compiles and loads modules.<br></div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>I guess that's what I"ve pickedup on -- "anti-ideas"? but these are key for some of us...<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span><div>I think it would be nice too. But what I hear from Stefan is that Cython's requirements are not a good fit for the proposal. And I believe it makes more sense to let Cython continue to do its own thing rather than trying to either expand the proposal so Cython can use it without change, or allow for alternate type notations so Cython can do its own thing. The latter however sounds closer to what's possible.<br></div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>maybe that will have to be the way to go -- but if still seems like we are building a too-limited system right up front -- that may be necessary to keep it from being too ugly. You've certainly been thinking about this a long time.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span><div>Everything in the proposal has a namespace (either 'typing' or 'builtins') and the checker is expected to understand and follow imports properly. So I don't see a problem here.<br></div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>OK -- that could be very helpful. <br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Anyway, I guess it's unclear to me whether the intent is to create a system that can be used for a static/run-time type checker like Cython.</div></div></div></div></blockquote><div><br></div></span><div>That is not the intent. (Though static and run-time seem two very different forms of type-checking. Apparently Cython does both?)</div></div></div></div></blockquote><div><br></div><div>well, if you typedef a name:<br><br></div><div>cdef int i<br><br></div><div>then Cython generates static C code that uses i as an int (C int in this case).<br><br></div><div>and if you typedef a function's parameters:<br><br></div><div>def func(int i):<br><br></div><div>then Cython generates code that tries to convert the argument to that type at run-time, raising an exception if it can't -- that's what i mean by run time type checking (I guess it's run-time type conversion, but it has to check in order to convert) <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>There have been a fair number of comments alone the lines of "this is only for lint-like static analysis". But I'd really love to see this move toward full functionailty.<br></div></div></div></div></blockquote><div><br></div></span><div>Once this proposal is in place you may try to adapt it for that purpose. But I'm not holding my breath, and I think we're better off with an imperfect proposal that can make it into 3.5 than with waiting until the ideal all-encompassing proposal is written.<br></div></div></div></div></blockquote><div><br></div><div>makes sense, but hopefully it will be an imperfect proposal that can evolve inot a more-perfect one in the future.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span><div>But in the case of Python, the performance thing is entirely unproven, and the focus on it is a hindrance to trying to get any type system at all introduced.<br></div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>Cython makes all the difference in the world for certain types of code. How is that unproven?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span><div>Nobody writes enough tests though, and type checking catches a different category of issues (shallow or not) than tests.<br></div></div></div></div></blockquote><div><br></div><div>well, hard to argue that catching more bugs isn't a good thing.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On the other hand, dynamic typing does impact performance in a way that effects my code -- so I tun to Cython (and sometimes C, C++, Fortran) to address those issues. (maybe JIT compilation will one day meet this need, but it hasn't yet).<br><br></div><div class="gmail_quote">So if there is type specifying, I want i to solve these problems.<br></div></div></div></blockquote><div><br></div></span><div>How?<br></div></div></div></div></blockquote><div><br></div><div>I meant that the new type specifying system should be usable by a static or JIT compiler to generate more optimized code -- i.e. Cython (or numba, or....)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">But where I'm lost is the utility of static analysis that is not used to either provide run-time type checking OR compile optimized code (either JIT or ahead-of-time). It seems that your entire system would have to be fully type-hinted to get the type safety. But once you've done that, why not just use a static language?<br></div></div></div></blockquote><div><br></div></span><div>However, gradual typing, for dynamically-typed languages, takes a different position. It claims that if you can type-check *some* of your program, the added type safety for that part helps find bugs. It's not a black or white situation. Just like a linter will find some bugs (after you wade through the false positives, tuning the linter options locally and globally to get a decent yield), a type checker of the kind proposed here will find some bugs (after you spend some time adding type annotations to part of the program).<br></div></div></div></div></blockquote><div><br></div><div>Again, hard to argue that catching more bugs isn't a good thing. But thanks, this makes it more clear to me what' meant by 'gradual typing" <br></div><div><br></div><div>I'm not sure that will satisfy the "enterprise" folks that really want static typing checking, but they can keep using Java, I guess.<br></div><div><br></div><div>I do wonder how much this will "infect" Python, and folks will add all this completely unnecessary type hinting that will just make it harder to use libraries off the shelf.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On the other hand, if run-time type checking is provided, then you could use that at the boundaries of your code base (kind of like Cython does) and get both the safety and performance benifits.<br></div></div></div><span class=""><div><br></div></span><div>But it sounds like it is Cython's job to do the checking at these boundaries. Isn't this similar to the way Python extensions written in C or C++ have to do type checking at the boundary between Python code and the extension? </div></div></div></div></blockquote><div><br></div><div>exactly -- all cython really does is write a C extension for you -- auto-generating all that boilerplate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The specification of these checks should be defined by Cython.</div></div></div></div></blockquote><div><br></div><div>Sure, but they are almost always a direct result of type, so all I do when I write cython is specify type. And as you point out about gradual typing, I don't need to specify type at all, Cython is perfectly happy working with python objects and leaving the type checking to run time.<br></div><div><br></div><div>But just as you can now run any (most, anyway...) python code through Cython, or would be great to be able to run any type annotated code through Cython, and hopefully get some benefit from the type annotations, and not have to essentially add redundant information.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I've read the MyPY FAQ, which does address these issues to some extent, but doesn't really make a compelling case to me, anyway.<br></div></div></div></blockquote><div><br></div></span><div>It did to me. :-) <br></div></div></div></div></blockquote><div><br></div><div>I'm getting close with your additional notes...<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I guess the gist here is that I think if Python is going to have an official type hinting system, it should leave the door open to compile time and run-time type checking. A good test case might be: can it be used for Cython? But this thread seems to be indicating that that is not the goal, and indeed, that it's almost an anti-goal. I hope I'm wrong about that.<span></span></div></div></div></blockquote><div><br></div></span><div>TBH I think the question of whether it can be used for Cython is still very much open. Why couldn't Cython take code that says a certain parameter has type List[int] and generate code from it?</div></div></div></div></blockquote><div><br></div><div>it probably could -- I think it's a good idea for us to start playing with that sort of thing.<br><br><br></div><div>-Chris<br><br></div></div><br>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>