"Edward C. Jones" <[EMAIL PROTECTED]> wrote:
> That's a good idea. Include everything from m * [n * [0]] to pickling
Except that it probably doesn't do what you intend...
>>> a = 2*[3*[0]]
>>> a
[[0, 0, 0], [0, 0, 0]]
>>> a[0][0] = 2
>>> a
[[2, 0, 0], [2, 0, 0]]
Unless
Ian Bicking:
>>> 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.
Brett Cannon:
>> I have to admit that is what I initially th
Guido van Rossum wrote:
> Its maps have methods to
> return keys, values and items, but these return neither new lists nor
> iterators; they return "views" which obey set (or multiset, in the
> case of items) semantics.
> I'd like to explore this as an alternative to making keys() etc.
> return i
Guido van Rossum wrote:
> If you find the 'empty' flag pattern too ugly, you can always write a
> helper class that takes an iterator and returns an object that
> represents the same iterator, but sometimes buffers one element.
Perhaps one of these could be included as
an itertool?
Greg
Ian Bicking wrote:
> Iterators look a lot like containers.
Actually, they hardly look like containers at all. About
the only thing you can do with a container that you can
also do with an iterator is use it in a for-loop. There
are a great many other things you *can't* do with an
iterator -- inde
Brett Cannon wrote:
> Someone else 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.
I have to agree that's actual
Alex Martelli wrote:
> Not sure what's a "small dict" in your world -- here, for example:
He's obviously talking about quantum dicts which
(averaged over a sufficiently large ensemble) contain
a fractional number of items.
Greg
___
Python-3000 mailing
Ian Bicking wrote:
> A downside is mistranslations of old code will lead to very hard bugs,
> as .keys() currently makes a copy. Though if the new objects aren't
> quite the same as lists -- e.g., implementing .add() instead of
> .append() -- then maybe that won't be so bad.
I'd suggest that
[EMAIL PROTECTED] wrote:
> Still, around work I see a great preference for the longer
> (and uglier IMO) spelling. Maybe it's a mental carryover from C++ that
> makes people what that version?
I think it's a natural tendency, and one that isn't
necessarily wrong to have. Although the iterator
ver
Ian Bicking wrote:
> If you could somehow count how many times
> the loop had run, that'd work great; but I don't see any way to do that
> without new syntax.
line = None
for line in some_lines:
...
if line is None:
# we didn't get any lines
Speculating on a syntax to make t
Adam DePrince wrote:
> Now, as for your example m * [ n * [0]], I would exclude it from a best
> practices document.
I'm assuming he meant the best-practices document would be
documenting how to do that *right*!
BTW, something I had in mind for the list comprehension
syntax back when it was bein
Delaney, Timothy (Tim) 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.
I'm not sure that any formal protocol is needed. Each
container will be providing
Steven Bethard wrote:
> There was talk previously_ about removing the else clause on for-loops
> (and while-loops). One possibility would be to change the else-clause
> to behave as expected above (i.e. only executed when the loop fails to
> iterate over any items).
I'm well aware that Python 30
Steven Bethard wrote:
>> There was talk previously_ about removing the else clause on for-loops
>> (and while-loops). One possibility would be to change the else-clause
>> to behave as expected above (i.e. only executed when the loop fails to
>> iterate over any items).
Fredrik Lundh:
> I'm well
Guido van Rossum wrote:
> On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> But I think if objects returned iterators instead of lists the
>> iterator-as-view will begin to be used more than viewing them as
>> iterator-has-own-data. But this also means that making a more
>> view-like interfac
Brett Cannon wrote:
> On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> (Off-topic: maybe we can drop the fall-back behavior
>> of iter() if __iter__ isn't found?)
>>
>
> I say yes. Iterators will be common enough that objects that want the
> support should just directly support it.
Hmm
Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Or a view would work just as well, I suppose. Maybe you've just made
>> the argument that it should return an iterable, not an iterator.
>
> Technically an iterator is an iterable, so requiring it to return an
> itera
Nicola Larosa wrote:
> Fredrik Lundh:
>> (fwiw, the else statement in Python *always* means the same thing: exe-
>> cute this when the controlling condition has been tested and found false)
>
> Precisely. And that's why the current behavior is counterintuitive: "no
> loops executed" is a better "f
On Thu, 2006-03-23 at 17:06 -0800, Guido van Rossum wrote:
> The pattern with the 'empty' flag is only needed when due to API
> constraints you have only got an iterator.
Which can happen quite often actually. Perhaps making the original
object available as an attribute of the iterator can help
On Fri, 2006-03-24 at 19:41 +1200, Greg Ewing wrote:
> 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 displ
On 3/24/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 17:06 -0800, Guido van Rossum wrote:
>
> > The pattern with the 'empty' flag is only needed when due to API
> > constraints you have only got an iterator.
>
> Which can happen quite often actually. Perhaps making the origi
Alex> Not sure what's a "small dict" in your world -- here, for example:
I would say "small" for us is typically fewer than ten keys. We rarely have
dictionaries with dozens or hundreds of keys.
Alex> python2.4 -mtimeit -s'd=dict.fromkeys(range(23))' 'for k, v in
d.iteritems(): pass'
On 3/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Someone else 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'
On 3/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> (Off-topic: maybe we can drop the fall-back behavior
> >> of iter() if __iter__ isn't found?)
> >
> > I say yes. Iterators will be common enough that objects t
On 3/24/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 17:06 -0800, Guido van Rossum wrote:
>
> > The pattern with the 'empty' flag is only needed when due to API
> > constraints you have only got an iterator.
>
> Which can happen quite often actually. Perhaps making the origi
Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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
On Fri, Mar 24, 2006, Greg Ewing wrote:
>
> I've speculated that perhaps it should be illegal to
> use an iterator that way, and you would instead have
> to say
>
>for x from iterator:
>
> This would force people to keep the distinction firmly
> in mind and might lead to less confusion.
How
On Fri, 2006-03-24 at 07:26 -0800, Guido van Rossum wrote:
> On 3/24/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-03-23 at 17:06 -0800, Guido van Rossum wrote:
> >
> > > The pattern with the 'empty' flag is only needed when due to API
> > > constraints you have only got an iterator.
On Fri, 2006-03-24 at 22:13 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
>
> > Now, as for your example m * [ n * [0]], I would exclude it from a best
> > practices document.
>
> I'm assuming he meant the best-practices document would be
> documenting how to do that *right*!
>
> BTW, somethi
Adam DePrince wrote:
> Now, as for your example m * [ n * [0]], I would exclude it from a best
> practices document. If your goal is to create a two dimensional array
> of numbers, it doesn't work. The first part, n* [0] is right, you are
> creating a list of n zeros, and when you say l[x]=y yo
[Nicola Larosa]
> ... I sometimes may have had a need for the current semantics
> of the else after loops, but I don't remember it; on the other hand, I have
> had a use for the no-iteration case a number of times. Somehow I find it
> hard to stick into my mind that's not what it means.
The primar
On 3/24/06, Charles Cazabon <[EMAIL PROTECTED]> wrote:
like 8-space indents would then start to argue vociferously about how manylevels of indentation are acceptable given an 80-character-wide source file.Don't forget those of us who are now pushing for 120 character wide source files!
-Kevin
_
On Fri, 2006-03-24 at 11:49 -0500, Kevin Jacobs wrote:
> On 3/24/06, Charles Cazabon <[EMAIL PROTECTED]> wrote:
> like 8-space indents would then start to argue vociferously
> about how many
> levels of indentation are acceptable given an
> 80-character-wide source
On Friday 24 March 2006 11:49, Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> Don't forget those of us who are now pushing for 120 character wide source
> files!
That would be bad. Do you realize just how small fonts would have to get to
let us still have as many editor windows on-screen? I don't
On Fri, 2006-03-24 at 12:11 -0500, Fred L. Drake, Jr. wrote:
> On Friday 24 March 2006 11:49, Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> > Don't forget those of us who are now pushing for 120 character wide source
> > files!
>
> That would be bad. Do you realize just how small fonts would have t
On 3/23/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> If we standardised on all-tabs, people could set their
> editors to display indentation however they wanted, and
> there would be no need to argue about how many spaces
> should be dancing at the head of a code line.
[and much followup]
Please t
Edward C. Jones wrote:
> I know its wrong. It was a mistake I made several times when I was
> earning Python. The m * [ n * [0]] problem is a dark corner of Python
> that exists because Python variables are really pointers. Unfortunately,
> this dark corner is visible to newbies. Which is why it n
--- Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I created this list a few days ago before Alan
> said he was interested in maintaining it. Tru64 is difficult (I think
> there are still some open bugs that go back years) because no
> developer has access to any of these boxes. It would be good for
>
On 3/24/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Nicola Larosa]
> > ... I sometimes may have had a need for the current semantics
> > of the else after loops, but I don't remember it; on the other hand, I have
> > had a use for the no-iteration case a number of times. Somehow I find it
> > hard
On 3/24/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I'm well aware that Python 3000 doesn't aim to be backwards compatible,
> but I would prefer if we could refrain from subtly changing the behaviour
> of existing constructs in way that breaks all existing use, and makes it un-
> necessarily har
On 3/24/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
...
> "my kids need braces, I'm going for a promotion!"
If your kids need braces, they'll find many more in C, Java, etc, than
in Python, where indentation prevails (unless you use a HUGE lot of
dictionary displays, of course).
Alex
___
On 3/24/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/24/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > I'm well aware that Python 3000 doesn't aim to be backwards compatible,
> > but I would prefer if we could refrain from subtly changing the behaviour
> > of existing constructs in way th
[Jim Fulton]
> ...
> I'd be interested to hear if other people who have experience working
> with ZODB BTrees have been as annoyed as I've been.
Not since the first week ;-), no. Two things exacerbate this in ZODB:
- BTrees are a mapping type, but unlike other mapping types its keys()
(etc) me
On 3/24/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> There's one other common surprise in Zope-land, namely that
>
> for key in b.keys():
> ... possibly try to delete `key` from `b`
>
> "doesn't work" when `b` is a BTree. The _expectation_, derived from
> experience with Python dicts, i
Guido van Rossum wrote:
> Python 3000 *will* be backwards incompatible, and sometimes it will be
> awkward to convert code. The question I lay in front of the community
> is, how much incompatibility can we handle? And what will the
> transition strategy be? Someone needs to own this discussion top
On 3/24/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Sure. I'll wait for some feedback in this thread, and then try to
> turn it into a transition-strategy PEP.
Excellent! Let me know when you're ready for feedback.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
[Tim]
>> ...
>> There's one other common surprise in Zope-land, namely that
>>
>> for key in b.keys():
>> ... possibly try to delete `key` from `b`
>>
>> "doesn't work" when `b` is a BTree. The _expectation_, derived from
>> experience with Python dicts, is that it's bulletproof, but t
On 3/24/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Guido]
> > The Java collections framework actually has an API and an idiom that
> > make this work: therd's a method on the *iterator* that deletes the
> > current item without disturbing the iteration.
>
> Yup, I saw that:
>
> http://java.su
Aahz wrote:
> On Fri, Mar 24, 2006, Greg Ewing wrote:
>> for x from iterator:
> How would you distinguish? What about objects that are their own
> iterator (such as files)?
Files would really and truly be iterators (i.e.
they would have a next() method) and you would
need to use
for line
Adam DePrince wrote:
> I'm curious, however, what do you envision the semantics of [x times i]
> being?
[x for _i in xrange(i)]
Greg
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
Tim Peters wrote:
> The primary use case is "search loops".
>
> for item in sequence:
> if desirable(item):
> break
> else:
> no desirable item exists
Except that almost all of my search loops are in
functions of their own, and I just use return.
So I don't get to use this use ca
Fred L. Drake, Jr. wrote:
> That would be bad. Do you realize just how small fonts would have to get to
> let us still have as many editor windows on-screen?
I'm still waiting for desk-sized displays with
stylus for input. Let's make the desktop metaphor
more than a metaphor!
Greg
Guido van Rossum wrote:
> Please tell me this whole thread is a cruel joke.
I know it isn't going to happen for Python, but
I seriously believe that all-tabs is a better
technical approach to program indentation, for
a variety of reasons. The only arguments against
it that I can see are legacy-re
On Sat, 2006-03-25 at 16:21 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
>
> > I'm curious, however, what do you envision the semantics of [x times i]
> > being?
>
>[x for _i in xrange(i)]
>
> Greg
So [[x times n] times m] would be really the same as n*[m*[0,]]
So its different than li
On Fri, 2006-03-24 at 18:58 -0800, Guido van Rossum wrote:
> On 3/24/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > [Guido]
> > > The Java collections framework actually has an API and an idiom that
> > > make this work: therd's a method on the *iterator* that deletes the
> > > current item without
On 3/24/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
[Guido]
> > Maybe. I need a volunteer to write the PEP!
>
> Oh, why not. Me me!
Excellent! Let us know when it's ready or when you'r stuck.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
__
56 matches
Mail list logo
