<div class="gmail_quote">Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> schrieb am Fri Jan 16 2015 at 22:31:11:<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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">i don’t think comments should ever have an impact on the code.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>They don't. They also change the errors emitted by the static checker (which is not invoked when you run the code -- it is like a linter).<br></div></div></div></div></blockquote><div><br>still, comments are in my eyes purely documentational. the only exception in python i can think of, doctest, only exists to ensure that no examples you give start breaking, i.e. doctests are ran to keep the *comments* up to date, not the code.<br><br>and annotations are a syntax-level element. using comments forces the linter to use an alternative AST with comments preserved, not the AST CPython gives you for free.<br><br>and i’m looking into the future: python interpreters/VMs could choose to optimize e.g. List[double] based on type annotations, instead of just linting. in which case comments would become part of the code.<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"><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>> i’d prefer “assert isinstance(...)” for type annotations on variables.<br></div><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But that *would* affect runtime, by slowing down execution. Also for generic types the type checking could be either very slow (if checking List[int] would check every item of a list) or always fail (if a type variable is involved).<br><br></div><div>See discussion at <a href="https://github.com/ambv/typehinting/issues/35" target="_blank">https://github.com/ambv/typehinting/issues/35</a><br></div></div></div></div></blockquote><div><br>optimized package builds strip out assertions, no? and if course isinstance([1], List[int]) shouldn’t fail. that would be very surprising!<br><br>i’ll check out the issue.<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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But there is a lot of code that really needs the concrete types. E.g. list+list returns a list, but sequence+sequence may fail (as list+tuple exemplifies). Or list.sort. Etc.<br></div></div></div></div></blockquote><div><br>i commented in the issue: we could specify that behavior in new ABCs or even add it as mixin methods. nothing prevents MutableSequence, which has .reverse, from having .sort, as well.<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"><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">will we be able to use Union[...] in places like an except clause, where tuples are used to mean the same right now? would make sense imho<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>No. Remember TOOWTDI. (Also the PEP intentionally stays far away from exception handling.)<br></div></div></div></div></blockquote><div><br>yeah, i just though that isinstance(foo, (str, bytes)) basically means “is foo an instance of either str or bytes”, or in other words “is foo an instance of the union type str|bytes”.<br><br>the one way to do it would have been Union[str, bytes] if python had Union from the beginning, i’m sure!<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"><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">what are ItemsView and KeysView for? what makes them different from FrozenSet or Sequence?<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_extra">They exist in collections.abc. Note that KeysView and ItemsView are (abstract) Sets, but ValuesView is not (you can have multiple equal values).<br></div></div></div></div></blockquote><div><br>ah, get it! they provide mixins powered by suppying a to-be-wrapped Mapping instance to MappingView’s __init__!<br><br>this should be documented, else nobody knows *how* they mix in their methods.<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 class="gmail_extra"><div>--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div></div></div></div></div></blockquote><div><br>thanks for the explanations, and as always: thanks for this most beautiful language :D <br></div></div>