> On Jan 23, 2017, at 12:10 PM, Brett Cannon <br...@python.org> wrote:
>
>
>
> On Mon, 23 Jan 2017 at 04:27 INADA Naoki <songofaca...@gmail.com
> <mailto:songofaca...@gmail.com>> wrote:
> On Mon, Jan 23, 2017 at 8:33 PM, Victor Stinner
> <victor.stin...@gmail.com <mailto:victor.stin...@gmail.com>> wrote:
> > 2017-01-23 12:25 GMT+01:00 INADA Naoki <songofaca...@gmail.com
> > <mailto:songofaca...@gmail.com>>:
> >> I gave advice to use 'List[User]' instead of List[User] to the team of
> >> the project,
> >> if the team think RAM usage or boot speed is important.
> >
> > I would prefer a Python option (ex: "-o noannotation" command line
> > option) to opt-out annotations rather than having to write annotations
> > in strings, which is IMHO more "ugly".
>
> So basically the equivalent of -OO for docstrings? Maybe this can be the
> final motivator for some of us to come up with a design to generalize -O or
> something as it keeps coming up.
Yes, please. We've talked about generalizing this for years now. FWIW, I know
of projects that run with -OO for the memory wins stemming from docstrings and
had to codemod assert statements into a "prod_assert" function call to achieve
this. If you think docstrings aren't that much, multiply this by a few hundred
processes on a box and it ends up being a substantial win to strip them out.
> >
> > Victor
>
> Personally speaking, I hope annotations are just static hint, and
> makes zero overhead at runtime.
> (startup time, memory consumption, and execution speed).
>
> Local variable annotations are nothing but info in the AST. Parameter
> annotations and class annotations are stored on their respective objects so
> there's memory usage from that and the construction of them at object
> creation time, but that's it (e.g. the cost of creating func.__annotations__
> when the function object is created is all you pay for performance-wise). And
> using strings will make those introspective attributes difficult to use,
> hence why I don't think people have said to do that everywhere.
I suggested making all annotations just strings at runtime and PEP 484 still
lists this as a possible course for the future. So far Guido blocked this on a
legitimate question: how much do type hints actually cost? Nobody knows yet,
the biggest annotated codebase is at Dropbox and this is using comments (so no
runtime cost).
>
> Anyway, many users are starting to use typing, for code completion or
> static checking.
> And very few user noticed it affects to performance of `isinstance(x,
> collections.Sequence)`.
> Python 3.7 may be too slow to help them.
> Can't we skip abc registration of typing.List[MyClass] completely?
>
> I'm sorry if it's silly idea. I don't know about background of
> current typing.py design. And I
> don't use abc much too.
>
> Since isinstance() checks are expected to be rare I don't think anyone has
> worried too much about the performance beyond the initial work to introduce
> ABCs and __instancecheck__.
Similar to the above, I would advise against crippling functionality unless we
prove this is affecting performance in a significant way.
- Ł
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
