On 3/28/06, adam deprince <[EMAIL PROTECTED]> wrote:
> > I won't go on any more - you probably get the idea...
>
> Agreed, scratch that, I'll rework it in the spriit of views.
Thanks for taking my comments so well! When I wrote them, I was
*really* worried they came across as too negative.
The ke
On Tue, 2006-03-28 at 17:04 +1200, Greg Ewing wrote:
> Some years ago there was a long discussion about extending
> the for-loop to express parallel iteration over a number
> of iterables, which ended with the conclusion that such
> an extension was syntactically impossible, and the creation
> of z
> for k in d: # or d.keys()
> for v in d.values():
> for k, v in d.items():
Right now I'm entertaining two competing "answers" to some of the issues
addressed in this thread. The first, and easiest to write about and
implement, was to make iters deletable to give the appearance of ha
> Agreed. I don't really see the relationship between this PEP and what
> went before. My understanding of the previous discussion was that
I know. Here is my start of a ViewInterface PEP. Its a closer match,
and a bit larger.
Updated versions can be found at http://deprince.net/ideas/pep-vi
On 3/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100. That
> gives plenty of room between any PEPs that might be written for 2.x and
> gives some space for various informational PEPs that are specific to Python
> 3.x.
I alread
On 3/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Some years ago there was a long discussion about extending
> the for-loop to express parallel iteration over a number
> of iterables, which ended with the conclusion that such
> an extension was syntactically impossible, and the creation
> of zip(
Greg Ewing writes:
> Some years ago there was a long discussion about extending
> the for-loop to express parallel iteration over a number
> of iterables
[...]
> I'm mentioning it here again just in case anyone wants
> to consider it for Py3k. I still believe it would be
> nice to have a di
Greg Ewing <[EMAIL PROTECTED]> wrote:
>for (x in iter1, y in iter2):
> ...
Contrary to zip()/izip(), this does not easily allow further composition, as
far as I can tell. For instance:
for i,(x,y) in enumerate(izip(iter1, iter2)):
...
must be translated to:
for (i,x in enumerate(i
>> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100
Guido> I already proposed that numbering scheme. More formally, Py3k
Guido> meta PEPs go between 3001 and 3099, and feature PEPs start at
Guido> 3100 (and hopefully we won't have to overflow into 4000 :-).
Sh
On 3/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Some years ago there was a long discussion about extending
> the for-loop to express parallel iteration over a number
> of iterables, which ended with the conclusion that such
> an extension was syntactically impossible, and the creation
> of zip(
On 3/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100
>
> Guido> I already proposed that numbering scheme. More formally, Py3k
> Guido> meta PEPs go between 3001 and 3099, and feature PEPs start at
> Guid
Guido van Rossum wrote:
>> Slightly too late for consideration, I did come up with
>> what I believe is a backwards-compatible syntax extension
>> to support this:
>>
>>for (x in iter1, y in iter2):
>> ...
[...]
> Based on the feedback so far I think not. There's also the issue that
>
>
Guido van Rossum wrote:
> On 3/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> >> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100
>>
>> Guido> I already proposed that numbering scheme. More formally, Py3k
>> Guido> meta PEPs go between 3001 and 3099, and f
[EMAIL PROTECTED] wrote:
> >> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100
>
> Guido> I already proposed that numbering scheme. More formally, Py3k
> Guido> meta PEPs go between 3001 and 3099, and feature PEPs start at
> Guido> 3100 (and hopefully we won't h
Guido van Rossum wrote:
> The proposed syntax doesn't quite jive with my guts, and the issue of
> "what to do if they are of unequal length" is a good one, which is
> better solved by being explicit and using zip (== izip).
Is zip() going to be equivalent to izip(), or will it be a view? I vote
On 3/28/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> There seems to be a danger that Py3K is seen as a more friendly place to
> suggest changes than Python 2.x (or maybe that the python-3000 list is
> more friendly to these suggestions than py-dev), and so changes are
> brought up here even thoug
On 3/28/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > >> Suggestion: Make this PEP 3001 and start any Py3k PEPs from 3100
> >
> > Guido> I already proposed that numbering scheme. More formally, Py3k
> > Guido> meta PEPs go between 3001 and 3099, and featu
On 3/28/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > The proposed syntax doesn't quite jive with my guts, and the issue of
> > "what to do if they are of unequal length" is a good one, which is
> > better solved by being explicit and using zip (== izip).
>
> Is zip() goi
Ian> There seems to be a danger that Py3K is seen as a more friendly
Ian> place to suggest changes than Python 2.x (or maybe that the
Ian> python-3000 list is more friendly to these suggestions than
Ian> py-dev), and so changes are brought up here even though they could
Ian> be
Ian Bicking wrote:
> Guido van Rossum wrote:
>
>>The proposed syntax doesn't quite jive with my guts, and the issue of
>>"what to do if they are of unequal length" is a good one, which is
>>better solved by being explicit and using zip (== izip).
>
>
> Is zip() going to be equivalent to izip(),
On 3/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I'm not concerned about that. Everyone here will ensure that if a
> feature should go into 2.x, it will. The feature may be implemented
> first in 3k, the PEP may be 3xxx, but when it's ready, it will migrate
> to 2.x also. This is important
>> No one is forgetting about 2.x by any means. There seemed to be
>> general consensus that there will be at least a couple more 2.x
>> releases. Or maybe that was just my view and no one disagreed. :-)
Guido> It's my view too.
Are you sure it's not your iter? ;-)
Skip
__
On 3/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I like your strawman: if incompatibilities or synergy
> don't require it to go into Py3k, let's propose it for 2.x.
Yeah, I think this makes a lot of sense - and we should probably
document it somewhere. Do you want this in the Backwards-I
Guido van Rossum wrote:
> I don't think there are enough dimensions in the numbering scheme to
> indicate all possible distinctions.
Dotted PEP numbers?
PEP numbers with keyword arguments? :-)
--
Greg
___
Python-3000 mailing list
[email protected]
Michael Chermside wrote:
> There's one big problem I see with this. Parallel iteration
> is underspecified... there are several reasonable choices
> for what to do if the iterables are of differing length.
I have trouble seeing that as a *big* problem.
I'd go for raising an exception (when in dou
Giovanni Bajo wrote:
> for i,(x,y) in enumerate(izip(iter1, iter2)):
> ...
>
> must be translated to:
>
> for (i,x in enumerate(iter1), y in iter2):
Maybe the functionality of enumerate() could be
incorporated into the syntax as well.
for (i in *, x in iter1, y in iter2):
...
--
G
Adam DePrince wrote:
> The first, and easiest to write about and
> implement, was to make iters deletable to give the appearance of having
> a view in what I thought was the only way we cared.
This is massively wrong. There's much more to the views
idea than just being able to delete things.
> I'
Adam DePrince wrote:
>The following interface names are abbreviations for the following
>permutations of the above.
>
>* Collection View( SetView + Multiview )
>* ListView: (SetView + MultiView + OrderedView)
>* OrderedSetView (SetView + OrderedView )
>* MapView( SetView +
Guido van Rossum wrote:
> for (x in A, y in B):
>
> could just as well be meant as a shortcut for
>
> for x in A:
> for y in B:
Well, the parens around the whole thing make it
look like a single tuple to me. But that could
just be because I already know what it's supposed
to mean.
Ulti
On 3/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam DePrince wrote:
>
> >The following interface names are abbreviations for the following
> >permutations of the above.
> >
> >* Collection View( SetView + Multiview )
> >* ListView: (SetView + MultiView + OrderedView)
> >* O
30 matches
Mail list logo
