2012/7/14 Alex Gaynor <alex.gay...@gmail.com>: > > > On Sat, Jul 14, 2012 at 4:18 PM, Benjamin Peterson <benja...@python.org> > wrote: >> >> 2012/7/14 Alex Gaynor <alex.gay...@gmail.com>: >> > >> > Proposal >> > ======== >> > >> > This PEP proposes formally documenting ``__length_hint__`` for other >> > interpreter and non-standard library Python to implement. >> > >> > ``__length_hint__`` must return an integer, and is not required to be >> > accurate. >> > It may return a value that is either larger or smaller than the actual >> > size of >> > the container. It may raise a ``TypeError`` if a specific instance >> > cannot have >> > its length estimated. It may not return a negative value. >> >> And what happens if you return a negative value? >> > > ValueError, the same as with len.
CPython will probably have to updated to not ignore it if you return "melons". > >> >> > >> > Rationale >> > ========= >> > >> > Being able to pre-allocate lists based on the expected size, as >> > estimated by >> > ``__length_hint__``, can be a significant optimization. CPython has been >> > observed to run some code faster than PyPy, purely because of this >> > optimization >> > being present. >> > >> > Open questions >> > ============== >> > >> > There are two open questions for this PEP: >> > >> > * Should ``list`` expose a kwarg in it's constructor for supplying a >> > length >> > hint. >> > * Should a function be added either to ``builtins`` or some other module >> > which >> > calls ``__length_hint__``, like ``builtins.len`` calls ``__len__``. >> >> Let's try to keep this as limited as possible for a public API. >> > > Sounds reasonable to me! Should we just go ahead and strip those out now? Certainly. -- Regards, Benjamin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
