[Python-Dev] PEP 0424: A method for exposing a length hint (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Jul 17 05:19:55 CEST 2012
- Previous message: [Python-Dev] PEP 0424: A method for exposing a length hint
- Next message: [Python-Dev] PEP 0424: A method for exposing a length hint
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jul 17, 2012 at 1:03 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
I've updated the PEP to reflect the discussion. There are two major changes:
1) NotImplemented may be used by lengthhint to indicate that there is no finite length hint available.
I've been thinking about this a bit more, and I think it does provide good scope for eventually adding length_hint to more iterators (including map, filter and enumerate).
2) callers of operator.lengthhint() must provide their own default value, this is also required by the current C PyObjectLengthHint implementation.
And this makes it explicit that API users need to deal with the AttributeError/NotImplemented case, whilst making it easy to do so. Good call.
There are no provisions for infinite iterators, that is not within the scope of this proposal.
I'll repeat my observation that remaining silent on this point is effectively identical to blessing the practice of raising an exception in length_hint to force fast failure of attempts to convert an infinite iterator to a concrete container. Rather than leaving people to figure this out on their own, we may as well make it official that TypeError can be raised in length_hint to block conversion to concrete containers that use a preallocation strategy.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PEP 0424: A method for exposing a length hint
- Next message: [Python-Dev] PEP 0424: A method for exposing a length hint
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]