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)
(modulo
[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 function or
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 data
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
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
work
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.
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, naturally. This
[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 the style
[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? (Hint:
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 consider using
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 English
[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
homonym that means
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
[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 to
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
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 Right. As a
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
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]) *
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
+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 it's for
+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 exactly
[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 without
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
[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_cue__
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
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.
No, it
26 matches
Mail list logo
