Re: [Python-Dev] _length_cue()
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 changes in the format of arguments, naturally. This simple one would
work for things like enumerate and reversed, though)
My goal here is not primarily to help debugging, but to help playing
around at the interactive command-line. Python's command-line should
not be dismissed as useless for real programmers; I definitely use it
all the time to try things out. 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
enumerate(spam)
enumerate(spam) # with your proposed extension -- not better
However, if this kind of goal is considered not serious enough for
adding a private special method, then I'm fine with trying out a fishing
approach.
For enhancing interactive usage, how about putting the special info and smarts
in help?
Or even a specialized part of help, e.g.,
help.explain(itertools.count(17))
or maybe
help.explore(itertools.count(17))
leading to an interactive prompt putting handy cmdwords in a line to get
easily to type, mro, non-underscore methods, attribute name list, etc.
E.g. I often find myself typing stuff like
[x for x in dir(obj) if not x.startswith('_')]
or
[k for k,v in type(obj).__dict__.items() if callable(v) and not
k.startswith('_')]
that I would welcome being able to do easily with a specialized
help.plaindir(obj)
or help.plainmethods(obj) or help.mromethods(obj) etc.
Hm, now that I think of it, I guess I could do stuff like that in site.py, since
help.plaindir = lambda x: sorted([x for x in dir(x) if not
x.startswith('_')])
help.plaindir(int)
[]
help.plaindir([])
['append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse',
'sort']
But some kind of standards would probably be nice for everyone if they like the
general idea.
I'll leave it to someone else as to whether and where a thread re help
enhancements
might be ok.
My .02USD ;-)
Regards,
Bengt Richter
___
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
Re: [Python-Dev] _length_cue()
[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 they assign it to a variable. The case of typing just, enumerate([1,2,3]), comes up only once, when first learning was enumerate() does. On the other hand, it's very common to see the iterator in the debug window showing the locals or the watches. And it's pretty easy to add some debugging print statement to the code, run the program/test, find out that, hey, that function returns an iterator, go back and add a list() around it to find out what's inside. I would welcome if the iterator repr string could show, when possible, the next couple of elements. Sorry, that's a pipe-dream. Real use-cases for enumerate() don't usually have the luxury of having an argument that is a sequence. Instead, you have to run the iteration a few steps to see what lies ahead. In general, this isn't always possible (stdin for example) or desirable (where the iterator is time consuming or memory intensive and so shouldn't be run unless the value is actually needed) or may even be a disaster (if the iterator participates in co-routine style code that expects to be passing control back and forth between multiple open iterators). IOW, you cannot safely run an iterator a few steps in advance, save-up the results for display, and then expect everything else to work right. I spent a good time of time pursuing this mirage, but there was no water: http://mail.python.org/pipermail/python-dev/2004-April/044136.html AFAICT, the only way to achieve the effect you want is to get an environment where all iterators are designed around an API that supports being run forward and backward (such as the one demonstrated by Armin at PyCon last year). Raymond ___ 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
Re: [Python-Dev] _length_cue()
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 inside automatically (but this hits problems of data structures being private). I thought that __getitem_cue__ would be a less dirty solution. I really think a better __repr__ would be generally helpful, and I cannot think of a 3rd solution at the moment... (Ideas welcome!) 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 for things like enumerate and reversed, though) If the subiterators themselves have decent repr methods, the top-level repr should also look reasonable. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] _length_cue()
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 intended these methods to be private and undocumented, not part of any official protocol in any way. A bientot, Armin ___ 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
Re: [Python-Dev] _length_cue()
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 for things like enumerate and reversed, though) My goal here is not primarily to help debugging, but to help playing around at the interactive command-line. Python's command-line should not be dismissed as useless for real programmers; I definitely use it all the time to try things out. 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 enumerate(spam) enumerate(spam) # with your proposed extension -- not better However, if this kind of goal is considered not serious enough for adding a private special method, then I'm fine with trying out a fishing approach. A bientot, Armin. ___ 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
Re: [Python-Dev] _length_cue()
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. 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 inside automatically (but this hits problems of data structures being private). I thought that __getitem_cue__ would be a less dirty solution. I really think a better __repr__ would be generally helpful, and I cannot think of a 3rd solution at the moment... (Ideas welcome!) A bientot, Armin ___ 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
Re: [Python-Dev] _length_cue()
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 simple one would work for things like enumerate and reversed, though) My goal here is not primarily to help debugging, but to help playing around at the interactive command-line. Python's command-line should not be dismissed as useless for real programmers; I definitely use it all the time to try things out. 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 enumerate(spam) enumerate(spam) # with your proposed extension -- not better However, if this kind of goal is considered not serious enough for adding a private special method, then I'm fine with trying out a fishing approach. Ah, I see the use case now. You're right in thinking I was mainly considering the debugging element (and supporting even that would be an improvement on the current repr methods, which are just the 'type with instance ID' default repr). In terms of what does it do though, I'd tend to actually iterate the thing: Py for x in enumerate(spam): print x ... (0, 's') (1, 'p') (2, 'a') (3, 'm') Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] _length_cue()
[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
used by xrange() and other repr's that can be run through eval(). Also, the
existing repr keeps its information up-to-date to reflect the current state
of the iterator:
it = count(10)
it.next()
10
it
count(11)
A good deal of thought and discussion went into these repr forms. See the
python-dev discussions in April 2004. Please don't randomly go in and
change those choices.
For most of the tools like enumerate(), there are very few assumptions you
can make about the input without actually running the iteration. So, I
don't see how you can change enumerate's repr method unless adopting a
combination of styles, switching back and forth depending on the input:
enumerate('abcde')
(0, 'a'), (1, 'b'), ...
enumerate(open('tmp.txt'))
enumerate object at 0x00BFD800
IMO, switching back and forth is an especially bad idea.
Hence, enumerate's repr ought to be left alone too.
Raymond
___
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
Re: [Python-Dev] _length_cue()
[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: consider the added difficulty for non-native English speakers). Skip ___ 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
Re: [Python-Dev] _length_cue()
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 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: consider the added difficulty for non-native English speakers). Skip ___ 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/jeremy%40alum.mit.edu ___ 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
Re: [Python-Dev] _length_cue()
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 speakers). Right. As a non-native speaker I can confirm that for English learners, cue is a bit mysterious at first while hint is obvious. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] _length_cue()
[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 something entirely different? (Hint: consider the added difficulty for non-native English speakers). Even as a native English speaker, but without knowing the intended meaning, I did not understand or guess that length_cue meant length_hint. The primary meaning of cue is 'signal to begin some action', with 'hint, suggestion' being a secondary meaning. Even then, I would take it as referring to possible action rather than possible information. Cue is also short for queue, leading to cue stick (looks like a pigtail, long and tapering) and cue ball. ___ 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
Re: [Python-Dev] _length_cue()
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 learners, cue is a bit mysterious at first while hint is Guido obvious. Guido, you're hardly your typical non-native speaker. I think your English may be better than mine. ;-) At any rate, I was thinking of some of the posts I see on c.l.py where it requires a fair amount of detective work just to figure out what the poster has written, what with all the incorrect grammar and wild misspellings. For that sort of person I can believe that cue, queue and kew might mean exactly the same thing... Skip ___ 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
Re: [Python-Dev] _length_cue()
[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 display more helpful information when playing around with them at the prompt, e.g.: enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596]) enumerate (0, 3.1), (1, 3.14), (2, 3.141),... length 6 At one point, I explored and then abandoned this idea. For objects like itertools.count(n), it worked fine -- the state was readily knowable and the eval(repr(obj)) round-trip was possible. However, for tools like enumerate(), it didn't make sense to have a preview that only applied in a tiny handful of (mostly academic) cases and was not evaluable in any case. That is my experience too. Even for knowable sequences people consume it in series and not just one element. My permutation module supports pulling out just the Nth canonical permutation. Lots of people have used the module and no one uses that feature. import probstat p = probstat.Permutation(range(4)) p[0] [0, 1, 2, 3] len(p) 24 p[23] [3, 2, 1, 0] -jackdied ___ 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
Re: [Python-Dev] _length_cue()
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.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
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 non-native speaker I can confirm that for English Guido learners, cue is a bit mysterious at first while hint is Guido obvious. Guido, you're hardly your typical non-native speaker. I think your English may be better than mine. ;-) At any rate, I was thinking of some of the posts I see on c.l.py where it requires a fair amount of detective work just to figure out what the poster has written, what with all the incorrect grammar and wild misspellings. For that sort of person I can believe that cue, queue and kew might mean exactly the same thing... FWIW, I first thought cue might be a typo mutation of clue ;-) +1 on something with hint. Regards, Bengt Richter ___ 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
[Python-Dev] _length_cue()
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 an iterator, for performance reasons. 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 implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. 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? 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 display more helpful information when playing around with them at the prompt, e.g.: enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596]) enumerate (0, 3.1), (1, 3.14), (2, 3.141),... length 6 A bientot, Armin ___ 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
Re: [Python-Dev] _length_cue()
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]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ 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
Re: [Python-Dev] _length_cue()
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 implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. Might I suggest that at least you consider using hint instead of cue? I'm pretty sure that hint has been in use for some time, and always to mean a value that can't be assumed to be correct but that improves performance if it is. For example, algorithms that insert values in balanced trees sometimes take hint arguments that suggest where the algorithm should start searching for the insertion point. ___ 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
Re: [Python-Dev] _length_cue()
+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 iterator classes only and it's documented. But now, consider: the CPython implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. Might I suggest that at least you consider using hint instead of cue? I'm pretty sure that hint has been in use for some time, and always to mean a value that can't be assumed to be correct but that improves performance if it is. For example, algorithms that insert values in balanced trees sometimes take hint arguments that suggest where the algorithm should start searching for the insertion point. ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] _length_cue()
+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 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 implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. Might I suggest that at least you consider using hint instead of cue? I'm pretty sure that hint has been in use for some time, and always to mean a value that can't be assumed to be correct but that improves performance if it is. For example, algorithms that insert values in balanced trees sometimes take hint arguments that suggest where the algorithm should start searching for the insertion point. ___ 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/ldlandis%40gmail.com -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ 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
Re: [Python-Dev] _length_cue()
[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 having the double-underscores around it. IMHO for safety reasons we need to stick double-underscores around this name too, e.g. __length_cue__(). The single underscore was meant to communicate that this method is private (which is why it is undocumented). Accordingly, the dir() function is smart enough to omit the method from its listing (which is a good thing). We follow similar naming conventions in pure Python library code. OTOH, this one is a bit different in that it is not truly private; rather, it is more like a friend method used internally for various tools to be able to communicate with each other. If you change to a double underscore convention, you're essentially making this a public protocol. IMHO, the safety reasons are imaginary -- the scenario would involve subclassing one of these builtin objects and attaching an identically named private method. All that being said, I don't feel strongly about it and you guys are welcome to change it if offends your naming convention sensibilities. [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. Also, to my ear, length_hint doesn't sound right. I'm -0 on changing the name. If you must, then go ahead. [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 display more helpful information when playing around with them at the prompt, e.g.: enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596]) enumerate (0, 3.1), (1, 3.14), (2, 3.141),... length 6 At one point, I explored and then abandoned this idea. For objects like itertools.count(n), it worked fine -- the state was readily knowable and the eval(repr(obj)) round-trip was possible. However, for tools like enumerate(), it didn't make sense to have a preview that only applied in a tiny handful of (mostly academic) cases and was not evaluable in any case. 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 they assign it to a variable. The case of typing just, enumerate([1,2,3]), comes up only once, when first learning was enumerate() does. Raymond ___ 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
Re: [Python-Dev] _length_cue()
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 iterator class, not necessary subclassing an existing one: class MyIter(object): ... def __iter__(self): ... return self ... def next(self): ... return whatever ... def _length_cue(self): ... print oups! please, CPython, don't call me unexpectedly ... list(MyIter()) oups! please, CPython, don't call me unexpectedly (...) This means that _length_cue() is at the moment a special method, in the sense that Python can invoke it implicitely. This said, do we vote for __length_hint__ or __length_cue__? :-) And does anyone objects about __getitem_hint__ or __getitem_cue__? Maybe __lookahead_hint__ or __lookahead_cue__? Armin ___ 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
Re: [Python-Dev] _length_cue()
[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__ unless someone has a strong objection. And does anyone objects about __getitem_hint__ or __getitem_cue__? Maybe __lookahead_hint__ or __lookahead_cue__? No objections here though I do question the utility of the protocol. It is going to be difficult to find pairs of objects (one providing the lookahead value and the other consuming it) that can make good use of the protocol. Outside of those unique pairings, there is no value at all. Thinking back over the code I ever seen, I cannot think of one case where the would have been helpful (except for the ill-fated adventure of trying to make iterators have more informative __repr__ methods). 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. Value pre-fetching has more utility in an environment where the concept is used everywhere (such as your lightning demo at PyCon last year where you ran iterators forwards/backwards and do tricks with infinite iterators). Outside of such an environment, I think it is going to be use-case challenged. Raymond ___ 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
Re: [Python-Dev] _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 __len_hint__ or __lenhint__. And does anyone objects about __getitem_hint__ or __getitem_cue__? I'm having trouble seeing widespread use cases for this. If an object is capable of computing arbitrary items on demand, seems to me it should be implemented as a lazily-evaluated sequence or mapping rather than an iterator. 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. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] _length_cue()
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 doesn't, because it's in the wrong direction. The caller isn't prompting the callee to perform an action, it's asking for some information. I agree that hint is a more precise name. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
