Adam DePrince wrote:
> Question #2:
>
> What should delete() return? I currently have it returning the iter
> itself to make it possible to say:
>
> value = iter.delete().next()
Python doesn't generally return self for call-chaining purposes. I'd
say delete() should return None.
--
Benji Yo
On 3/26/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> I have a draft PEP and an implementation of mutable iterators for lists
> and dicts that supports delete only.
>
> The PEP (Mutable Iterations) and sample code can be found at:
>
> http://www.deprince.net/ideas/peps.html
I think the PEP really
The (pre-)PEP should be mostly self-explanatory. I'm trying to lay
down some guidelines for how backwards-incompatible changes should be
introduced in Python 3000. Feedback is greatly appreciated,
especially in the Identifying Correct Code section.
PEP: XXX
Title: Procedure for PEPs with Backwa
On 3/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/26/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> > I have a draft PEP and an implementation of mutable iterators for lists
> > and dicts that supports delete only.
> >
> > The PEP (Mutable Iterations) and sample code can be found at:
> >
On 3/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> The (pre-)PEP should be mostly self-explanatory. I'm trying to lay
> down some guidelines for how backwards-incompatible changes should be
> introduced in Python 3000. Feedback is greatly appreciated,
> especially in the Identifying Correct
On 3/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Requiring code that can identify things in 2.x that will change in 3.0
> that are coded externally from the interpreter is going to be *really*
> difficult in some situations, if not impossible to get right. Just
> look at dict.items(); how do
On 3/26/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> [ On porting Java Iterators to python ]
Summary of my response:
Add a (convention of an) "exhausted" property that indicates
whether the iterator is used up, without wasting a value.
Add a conventional name for a reference to the underlying
On Mon, Mar 27, 2006, Steven Bethard wrote:
>
> Abstract
>
>
> This PEP describes the procedure for changes to Python that introduce
> backwards incompatible changes between the Python 2.X series and
> Python 3000. All such changes must be documented by an appropriate
> Python 3000 PEP an
On 3/27/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 27, 2006, Steven Bethard wrote:
> >
> > Abstract
> >
> >
> > This PEP describes the procedure for changes to Python that introduce
> > backwards incompatible changes between the Python 2.X series and
> > Python 3000. All such change
Steven> The (pre-)PEP should be mostly self-explanatory
Steven> PEP: XXX
Steven> Title: Procedure for PEPs with Backwards-Incompatible Changes
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
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().
Slightly too late for consideration, I did come up with
> I won't go on any more - you probably get the idea...
Agreed, scratch that, I'll rework it in the spriit of views.
Cheers, Adam DePrince
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscrib
> I think an even bigger problem is either
> (1) checking isvalid on every *lookup*, or
> (2) the mess and inefficiency of forcing every (mutable) collection to
> (weakly) track all its iterators, and forcing every iterator to have
> methods for handling notification. (So now "for k in dict" n
13 matches
Mail list logo
