Looking over some of the messages in the archives, I saw a reference
to making dict keys, items, and values methods return iterators. I've heard
Guido mention this in the past.
I'd like to offer a word of caution here. ZODB has a BTree implemention
that uses iterators for keys, values, and item
Jim Fulton wrote:
> Looking over some of the messages in the archives, I saw a reference
> to making dict keys, items, and values methods return iterators. I've heard
> Guido mention this in the past.
I saw this too in the archives, and thought shit, that's going to mess
up a lot of my code. I
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> One idea I had after reading a post of Brett's was a dual-use attribute;
> if you do d.keys you get an iterable (not an iterator, of course), and
> if you call that iterable you get a list. This is backward compatible,
> arguably prettier anyway
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Jim Fulton wrote:
> > Looking over some of the messages in the archives, I saw a reference
> > to making dict keys, items, and values methods return iterators. I've heard
> > Guido mention this in the past.
It's been one of the first things I'v
Guido van Rossum wrote:
...
> I've read and re-read Jim's message, and I'm not sure I understand it.
> It seems he's working in an interactive session
Yup
> but I'm not sure I
> understand the problem he has with adding list() around an expression
It's a hassle.
> (unless he hasn't got readlin
On Thu, 2006-03-23 at 14:52 -0500, Jim Fulton wrote:
> If we are dead set on making these methods return iterators, I'd really like
> to see a way to either get non-iterators by calling a method or see some
> new facilities in the iterators returned. Perhaps these iterators
> could have a method
Guido> It's interesting to me because there's a bunch of APIs that
Guido> currently have two versions: one to get a list and one to get an
Guido> iterator. It would be cleaner if only the iterator version
Guido> existed, and the way to get a list was to put an explicit list()
G
On 3/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
...
> Agreed. I think there's also a perceived performance difference, whether
> one exists or not. I'd be real surprised if
>
> for key, val in somedict.iteritems():
> blah(key, val)
>
> was faster than
>
> for key, val
On 3/23/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> ...
> > I've read and re-read Jim's message, and I'm not sure I understand it.
> > It seems he's working in an interactive session
>
> Yup
Feedback taken. But I don't want to design the feature or base its
user testing e
Guido van Rossum:
> > I've read and re-read Jim's message, and I'm not
> > sure I understand it. It seems he's working in
> > an interactive session but I'm not sure I
> > understand the problem he has with adding list()
> > around an expression
Jim Fulton wrote:
> It's a hassle.
> ...
> I'd be in
On 3/23/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> It is a hassle. I recently changed my ORM's API from returning iterators
> to lists based on similar user feedback (and I could have sworn I
> already made this comment on this issue, but I can't find it now). That
> experience hints to me that
Robert Brewer wrote:
> Guido van Rossum:
>
>>>I've read and re-read Jim's message, and I'm not
>>>sure I understand it. It seems he's working in
>>>an interactive session but I'm not sure I
>>>understand the problem he has with adding list()
>>>around an expression
>
>
> Jim Fulton wrote:
>
>>I
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> This has been my personal experience with the iterators in SQLObject as
> well. The fact that an empty iterator is true tends to cause particular
> problems in that case, though I notice iterkeys() acts properly in this
> case; maybe part of the
Guido van Rossum wrote:
>>I saw this too in the archives, and thought shit, that's going to mess
>>up a lot of my code. I would assume (though it's a separate point of
>>discussion) that Python 3k should still try hard to keep backward
>>compatibility. Backward compatibility isn't a requirement,
Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>This has been my personal experience with the iterators in SQLObject as
>>well. The fact that an empty iterator is true tends to cause particular
>>problems in that case, though I notice iterkeys() acts properly in t
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> >
> >>This has been my personal experience with the iterators in SQLObject as
> >>well. The fact that an empty iterator is true tends to cause particular
> >>proble
Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>Guido van Rossum wrote:
>>
>>>On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>>
>>>
This has been my personal experience with the iterators in SQLObject as
well. The fact that an empty iterator is true t
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
[Guido]
> > Testing whether an iterator is empty or not is an oxymoron; the only
> > legit way is to call next() and see whether it raises StopIteration.
> > This is the fundamental confusion I am talking about. It is NOT
> > "natural enough". It r
Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [Guido]
>
>>>Testing whether an iterator is empty or not is an oxymoron; the only
>>>legit way is to call next() and see whether it raises StopIteration.
>>>This is the fundamental confusion I am talking about. It is NO
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >>I saw this too in the archives, and thought shit, that's going to mess
> >>up a lot of my code. I would assume (though it's a separate point of
> >>discussion) that Python 3k should still try hard to keep backward
> >
Ian Bicking wrote:
> Coming back around to the idea of implementing __getitem__ and such, I
> suppose a list-like iterator wrapper could be useful. That would
> consume and retain the results of the iterator lazily to satisfy the
> things done to the object. That would be kind of interesting;
On Thu, 2006-03-23 at 16:02 -0800, Brett Cannon wrote:
> I don't think things are going to be broken gratuitously.
However, I hope we don't throw out clearly beneficial improvements for
backward compatibility's sake. But yes, all things being equal, if it
comes down to a tie-breaker then backwar
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > [Guido]
> >>>Testing whether an iterator is empty or not is an oxymoron; the only
> >>>legit way is to call next() and see whether it raises StopIteration.
> >>>Th
On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > Testing whether an iterator is empty or not is an oxymoron; the only
> > > legit way is to call next() and see whether it raises StopIteration.
> > > This is the fundamental
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
[SNIP]
> I'm testing if it is empty or not, which seems natural enough. Or would
> be, if it worked. So I start out doing:
>
>for item in select_results: ...
>
>
Guido van Rossum wrote:
>>In SQLObject it came about due to a desire to lazily load objects out of
>>a query. The lazy behavior had other problems (mostly introducing
>>concurrency where you wouldn't expect). In addition, the query is only
>>run when you start iterating. I'm not sure if that is
On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > When I was just
> > first learning Python I thought this would work:
> >
> >for item in select_results:
> >...
> >else:
> >... stuff when there are no items ...
> >
>
On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I think there is a fundamental difference between your views of
> iterators. It sounds like Ian is viewing them as a separate object;
> something that happens to have derived its values from a dict in the
> situation begin discussed. While it
Guido van Rossum wrote:
> But this is only needed if *all you have* is the iterator. Most of the
> time, the code containing the for loop has access to the container,
> and the iterator is only instantiated by the __iter__() call implied
> by the for loop.
I don't think that is the case. For inst
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Empty iterator or iterator that produced no items -- from the outside
> it's the same use case.
I see it as an education issue. Because we have generators, the
iterator protocol can't be extended to support a test for emptiness --
that's just no
On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > > When I was just
> > > first learning Python I thought this would work:
> > >
> > >for item in select_results:
> > >.
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > But this is only needed if *all you have* is the iterator. Most of the
> > time, the code containing the for loop has access to the container,
> > and the iterator is only instantiated by the __iter__() call implied
>
On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > I think there is a fundamental difference between your views of
> > iterators. It sounds like Ian is viewing them as a separate object;
> > something that happens to have derived its v
Guido van Rossum wrote:
> On 3/23/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > It is a hassle. I recently changed my ORM's API from
> > returning iterators to lists based on similar user
> > feedback (and I could have sworn I already made
> > this comment on this issue, but I can't find it
> >
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> When I was just first learning Python I thought this would work:
>
>for item in select_results:
>...
>else:
>... stuff when there are no items ...
>
> But it doesn't work like that.
On 3/23/06, Brett Cannon <[EMAIL PROTEC
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
> Right. I am really starting to think that having a group of Best
> Practices essays that discuss common Python idioms might be handy.
> Part tutorial, part advanced usage, they would provide a way for
> people to have a place to go to find out expec
Jeremy Hylton wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> One idea I had after reading a post of Brett's was a dual-use
>> attribute; if you do d.keys you get an iterable (not an iterator, of
>> course), and if you call that iterable you get a list. This is
>> backward compatib
Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> But this is only needed if *all you have* is the iterator. Most of the
>>> time, the code containing the for loop has access to the container,
>>> and the iterator is only instantiated by the
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
[...]
> To me that feels like a big transformation, where I would prefer to just
> be able to use "non_empty_lines(lines)" in place of "lines" and
> everything would work perfectly.
Well wishing ain't going to make it so. I'm not sure what you're
On 3/23/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> This whole discussion suggests to me that what would be best is if we
> defined an actual "view" protocol, and various builtins return views,
> rather than either copies or iterators.
Right.
> A view provides the same access methods,
On Thu, Mar 23, 2006 at 05:27:48PM -0800, Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > Empty iterator or iterator that produced no items -- from the outside
> > it's the same use case.
>
> I see it as an education issue. Because we have generators, the
> iterato
On Fri, 2006-03-24 at 13:15 +1100, Delaney, Timothy (Tim) wrote:
> Jeremy Hylton wrote:
>
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> >> One idea I had after reading a post of Brett's was a dual-use
> >> attribute; if you do d.keys you get an iterable (not an iterator, of
> >> course)
On Thu, Mar 23, 2006, Guido van Rossum wrote:
> On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>
>> I understand Ian's view since I know I like to pass around iterators
>> for use and that disconnects the iterator from the object that
>> generated it and thus makes it impossible to find out
On Thu, 2006-03-23 at 21:05 -0500, Edward C. Jones wrote:
> "Brett Cannon" <[EMAIL PROTECTED]> wrote:
>
> > Right. I am really starting to think that having a group of Best
> > Practices essays that discuss common Python idioms might be handy.
> > Part tutorial, part advanced usage, they would
Guido van Rossum wrote:
> That won't go away for me (Google's settings default to TWO-space
> indents :-( ) but I agree with the 4-space indent -- eventually.
If we standardised on all-tabs, people could set their
editors to display indentation however they wanted, and
there would be no need to a
45 matches
Mail list logo
