On Fri, 10 Feb 2006 14:33:08 +0100, Armin Rigo <[EMAIL PROTECTED]> wrote:
>Hi Nick,
>
>On Fri, Feb 10, 2006 at 11:21:52PM +1000, Nick Coghlan wrote:
>> Do they really need anything more sophisticated than:
>>
>>def __repr__(self):
>> return "%s(%r)" % (type(self).__name__, self._subiter)
[Armin]
> It would be nicer if all these
> iterators I'm not familiar with would give me a hint about what they
> actually return, instead of:
>
itertools.count(17)
> count(17) # yes, thank you, not very helpful
I prefer that the repr() of count() be left alone. It follows t
Armin Rigo wrote:
> Hi Nick,
>
> On Fri, Feb 10, 2006 at 11:21:52PM +1000, Nick Coghlan wrote:
>> Do they really need anything more sophisticated than:
>>
>>def __repr__(self):
>> return "%s(%r)" % (type(self).__name__, self._subiter)
>>
>> (modulo changes in the format of arguments, natu
Hi Raymond,
On Wed, Feb 08, 2006 at 09:21:02PM -0500, Raymond Hettinger wrote:
> (... __getitem_cue__ ...)
> Before putting this in production, it would probably be worthwhile to search
> for code where it would have been helpful. In the case of __length_cue__,
> there was an immediate payoff.
Hi Nick,
On Fri, Feb 10, 2006 at 11:21:52PM +1000, Nick Coghlan wrote:
> Do they really need anything more sophisticated than:
>
>def __repr__(self):
> return "%s(%r)" % (type(self).__name__, self._subiter)
>
> (modulo changes in the format of arguments, naturally. This simple one would
Hi Greg,
On Thu, Feb 09, 2006 at 04:27:54PM +1300, Greg Ewing wrote:
> The iterator protocol is currently very simple and
> well-focused on a single task -- producing things
> one at a time, in sequence. Let's not clutter it up
> with too much more cruft.
Please refer to my original message: I in
Armin Rigo wrote:
> Indeed, I don't foresee any place where it would help apart from the
> __repr__ of the iterators, which is precisely what I'm aiming at. The
> alternative here would be a kind of "smart" global function that knows
> about many built-in iterator types and is able to fish for the
[Giovanni]
>> I was really attracted to the idea of having more informative iterator
>> representations but learned that even when it could be done, it wasn't
>> especially useful. When someone creates an iterator at the
>> interactive
>> prompt, they almost always either wrap it in a consumer fun
On Thu, 9 Feb 2006 09:54:59 -0600, [EMAIL PROTECTED] wrote:
>
>>> Ditto. In addition, we already have queues. Do we really need to
>>> use a homonym that means something entirely different? (Hint:
>>> consider the added difficulty for non-native English speakers).
>
>Guido> Righ
> Hint seems like the standard terminology in the field. I don't think
> it makes sense to invent our own terminology without some compelling
> reason.
Okay, I give, hint wins.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
[Raymond Hettinger]
> [Armin Rigo]
> > BTW the reason I'm looking at this is that I'm considering adding
> > another undocumented internal-use-only method, maybe __getitem_cue__(),
> > that would try to guess what the nth item to be returned will be. This
> > would allow the repr of some iterators
>> Ditto. In addition, we already have queues. Do we really need to
>> use a homonym that means something entirely different? (Hint:
>> consider the added difficulty for non-native English speakers).
Guido> Right. As a non-native speaker I can confirm that for English
Guido
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>>>> Might I suggest that at least you consider using "hint" instead of
> "cue"?
>...
>
>Greg> I agree that "hint" is a more precise name.
>
> Ditto. In addition, we already have queues. Do we really need to use a
> homony
On 2/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Greg> I agree that "hint" is a more precise name.
>
> Ditto. In addition, we already have queues. Do we really need to use a
> homonym that means something entirely different? (Hint: consider the added
> difficulty for non-native Engl
Hint seems like the standard terminology in the field. I don't think
it makes sense to invent our own terminology without some compelling
reason.
Jeremy
On 2/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> [Andrew Koenig]
> >>
> >>> Might I suggest that at least you consi
>> [Andrew Koenig]
>>
>>> Might I suggest that at least you consider using "hint" instead of
"cue"?
...
Greg> I agree that "hint" is a more precise name.
Ditto. In addition, we already have queues. Do we really need to use a
homonym that means something entirely different
Raymond Hettinger wrote:
> [Andrew Koenig]
>
>>Might I suggest that at least you consider using "hint" instead of "cue"?
>
> Personally, I prefer "cue" which my dictionary defines as "a signal, hint,
> or suggestion". The alternate definition of "a prompt for some action"
> applies equally well
Armin Rigo wrote:
> This said, do we vote for __length_hint__ or __length_cue__? :-)
I prefer something containing "hint" rather than "cue"
because it more explicitly says what we mean.
I feel that __length_hint__ is a bit long, though.
We have __len__, not __length__, so maybe it should
be __le
[Armin Rigo]
> Hi Raymond,
. . .
> This means that _length_cue() is at the moment a special method, in the
> sense that Python can invoke it implicitely.
Okay, that makes sense. Go ahead and make the swap.
> This said, do we vote for __length_hint__ or __length_cue__? :-)
I prefer __length_cu
Hi Raymond,
On Wed, Feb 08, 2006 at 03:02:21PM -0500, Raymond Hettinger wrote:
> IMHO, the "safety reasons" are imaginary -- the scenario would involve
> subclassing one of these builtin objects and attaching an identically named
> private method.
No, the senario applies to any user-defined ite
[Armin Rigo]
> It was replaced by an optional undocumented method called _length_cue(),
> which would be used to guess the number of remaining items in an
> iterator, for performance reasons.
>
> I'm worried about the name. There are now exactly two names that behave
> like a special method withou
+1 on 'hint' vs 'cue'... also infers 'not definitive' (sort of like having a
hint of how much longer the "honey do" list is... the honey do list is
never 'exhaustive', only exhausting! ;-)
On 2/8/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I'm worried about the name. There are now ex
+1 for __length_hint__. Raymond?
On 2/8/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I'm worried about the name. There are now exactly two names that behave
> > like a special method without having the double-underscores around it.
> > The first name is 'next', which is kind of fine because i
> I'm worried about the name. There are now exactly two names that behave
> like a special method without having the double-underscores around it.
> The first name is 'next', which is kind of fine because it's for
> iterator classes only and it's documented. But now, consider: the
> CPython imple
On Wed, Feb 08, 2006, Armin Rigo wrote:
>
> IMHO for safety reasons we need to stick double-underscores around this
> name too, e.g. __length_cue__(). It's new in 2.5 and not documented
> anyway so this change won't break anything. Do you agree with that?
+1
--
Aahz ([EMAIL PROTECTED])
Hi all,
Last september, the __len__ method of iterators was removed -- see
discussion at:
http://mail.python.org/pipermail/python-dev/2005-September/056879.html
It was replaced by an optional undocumented method called _length_cue(),
which would be used to guess the number of remaining items in
26 matches
Mail list logo
