I'm a newbie when it comes to deep Python internals, so maybe I'm
missing something obvious. I'm trying to figure out the right answer
for exceptions/tracebacks in PEP 3101 (advanced string formatting).
Because the PEP 3101 string formatting is so much more powerful than
the existing %s, it seems
Patrick Maupin wrote:
> 1) What is the best thing to do right now for PEP3101?
>
> 2) If the "right now" answer isn't very good, is this really a more
> general problem that needs work? As more "little languages" do things
> like manipulate the AST, it might become very useful to have the
> abili
I'm a newbie when it comes to deep Python internals, so maybe I'm
missing something obvious. I'm trying to figure out the right answer
for exceptions/tracebacks in PEP 3101 (advanced string formatting).
Because the PEP 3101 string formatting is so much more powerful than
the existing %s, it seems
On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> > We don't suggest that file-like objects
> > should implement __read__() instead of read(), for example.
>
> There is a convention and it is applied quite consistently:
>
> Double-underscores are
On Mon, 5 Mar 2007, Greg Falcon wrote:
> I agree that file.read() is a different beast than iter.next().
> However, file.write() is a counterexample to your argument here. It
> gets called by Python syntax, and yet doesn't (and shouldn't) have
> double underscores.
>
> >>> print >> object(), "foo"
On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> The argument that all "protocol" methods should have double
> underscore names seems to be pretty weak too. It's only an appeal
> for consistency, I think. We don't suggest that file-like objects
> should implement __read__() instead of read(), for ex
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
|
| > One of the virtues, and as I recall, design purposes, of .next calls is
to
| > be fast. After the first call, execution jumps directly into the
| > pre-existing stack frame.
|
| You're thinking o
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> This is exactly why the iterator protocol method should be named
> __next__: so it can't collide with method names used for other
> purposes.
And yet people are suggesting that __call__ be used instead of
__next__. If people believe iterators should be sep
Josiah Carlson wrote:
> It's already spelled...
>
> for item in iter:
> #code for when we got something
> break
> else:
> #code for when we didn't get anything
Technically this is true, but I can't help feeling
that's a terribly obscure way to use a for-loop.
Norm
Aahz wrote:
> I'm +0 on operator.next() relative to builtin next().
I'm -0.7. Classifying next() as an operator doesn't
seem right -- what "operator" does it correspond to?
Unlike all the other functions in the operator
module, there is no piece of syntax that corresponds
directly to what next()
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Georg Brandl wrote:
>
> > Indeed, you almost always have to have a try-except StopIteration-
> > wrapper around "manual" calls to .next().
The use-cases would likely be analagous to the .find() vs. .index()
methods on strings.
Then again, while I prefe
On Mon, Mar 05, 2007, Ka-Ping Yee wrote:
>
> Abstract
>
>
> The iterator protocol in Python 2.x consists of two methods:
> ``__iter__()`` called on an iterable object to yield an iterator, and
> ``next()`` called on an iterator object to yield the next item in the
> sequence. Using a ``f
Raymond Hettinger wrote:
> Do you expect that next(someiterator) will be just
> as fast and calling a boundmethod (such as:
> counter=itertools.counter(1); counter())?
If you snarf a local reference to the next()
function, I expect it will be comparable in the
case where the iterator is implement
[Josiah Carlson]
>> I have written methods named 'next' which have *nothing* to do
>> with the iterator protocol.
[Greg]
>That would be another reason for renaming .next() to
>.__next__() -- to avoid intruding on the user's
>namespace.
Another read is that iterators should be separate
objects s
Josiah Carlson wrote:
> I have written methods named 'next' which have *nothing* to do
> with the iterator protocol.
That would be another reason for renaming .next() to
.__next__() -- to avoid intruding on the user's
namespace.
--
Greg
___
Python-3000
[Greg Ewing]
>Invoking a builtin .next() method via a protocol
>function shouldn't be any slower than it is now.
>In both cases you've got one name lookup and one
>Python call, after which you go through the type
>slot directly to a C function.
Do you expect that next(someiterator) will be just
as
Georg Brandl wrote:
> Indeed, you almost always have to have a try-except StopIteration-
> wrapper around "manual" calls to .next().
An alternative way of addressing this would be to
have a new control structure. We already have the
'for' statement for when you want all the values;
why not anothe
Terry Reedy wrote:
> One of the virtues, and as I recall, design purposes, of .next calls is to
> be fast. After the first call, execution jumps directly into the
> pre-existing stack frame.
You're thinking of generators, but not all iterators
are implemented by generators. The built-in ones a
Ka-Ping Yee wrote:
> PEP 234 (it amuses me that the PEP number for iterators is
> three digits in arithmetic sequence)
I guess the equivalent PEP for Py3k should be
numbered PEP 3456 then. :-)
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 5:45 PM, Greg Ewing wrote:
> Ka-Ping Yee wrote:
>
>> Just like getattr, two-argument next(iter, sentinel)
>> returns sentinel if StopException is caught.
>
> +1. I've written a number of pieces of code where this
> would hav
On Mon, 5 Mar 2007, Josiah Carlson wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> However, I have written methods named 'next' which have *nothing* to do
> with the iterator protocol.
This is exactly why the iterator protocol metho
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > because [...] 2) it renames a protocol method, making it
> > potentially difficult and/or buggy to write forward or backward
> > compatible code, [...]
>
> Did you see my slides and/or video o
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Can I suggest that next() and __next__() be dropped entirely and that
iterators just be made callable.
Can you do that without making the call a regular, slow call each time?
Or at least without adding a lookup of '__call__' each tim
Greg Ewing schrieb:
> Ka-Ping Yee wrote:
>
>> Just like getattr, two-argument next(iter, sentinel)
>> returns sentinel if StopException is caught.
>
> +1. I've written a number of pieces of code where this
> would have made things neater. Just about any place
> where I've used .next() exp
Ka-Ping Yee wrote:
> Just like getattr, two-argument next(iter, sentinel)
> returns sentinel if StopException is caught.
+1. I've written a number of pieces of code where this
would have made things neater. Just about any place
where I've used .next() explicitly, in fact -- it
always seem
[Raymond]
>> My thought here is that iterators should always be a separate object --
>> there is no good reason for dir(iter(myfile)) to expose methods that have
>> nothing to do with iteration. In the case of files, it would not be hard to
>> have a singleton file-iterator object.
[GvR]
>The
On Mon, 5 Mar 2007 [EMAIL PROTECTED] wrote:
> And, more importantly, it is butt-ugly.
What part exactly? Does this bother you:
def __next__(self):
...
or this:
while whatever:
x = next(i)
...
They look pretty much like the rest of Python to me.
-- ?!ng
__
On Mon, 5 Mar 2007 [EMAIL PROTECTED] wrote:
> Can I suggest that next() and __next__() be dropped entirely
> and that iterators just be made callable.
We went through a long discussion about this when iterators
were being figured out the first time around -- in fact, using
__call__ was the origina
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 5:16 PM, Greg Ewing wrote:
> Also I'm not sure I like this idea. It smells like
> an abuse of the notion of calling to me. One doesn't
> normally expect that calling a callable object has
> a side effect on the callable itself.
Per
"Ka-Ping Yee" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On the consistency argument: sorted(somelist) calls copy(somelist).sort,
not copy(somelist).__sort__. But I don't expect to see this change
proposed.
| Transition Plan
| ===
|
| Two additional transformati
Barry Warsaw wrote:
> OTOH, making iterators callable as equivalent to .next() as I think
> Raymond suggested sounds about perfect. You get __next__(), plus
> explicit iteration with no additional built in necessary.
But that would raise the question of why __next__
wasn't called __call__ in
On 3/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> My thought here is that iterators should always be a separate object -- there
> is no good reason for dir(iter(myfile)) to expose methods that have nothing
> to do with iteration. In the case of files, it would not be hard to have a
> si
On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> because [...] 2) it renames a protocol method, making it
> potentially difficult and/or buggy to write forward or backward
> compatible code, [...]
Did you see my slides and/or video of my talk about Py3k yet? This
change can be carried out au
At 10:48 AM 3/5/2007 -0800, Guido van Rossum wrote:
>I fear that the optimizations
>we've implemented for calling tp_next (especially for built-in
>iterators like list or dict iterators). Since tp_call must be usable
>in other contexts, and has much more optional features, it will be
>hard to carry
[Ka-Ping]
> Title: Renaming iterator.next() to iterator.__next__()
> ==
[Josiah]
> It sounds and reads just fine, though I'm -1 on the change
> if only because 1) it adds a builtin, 2) it renames a
> protocol method, making it potentially diffic
[Raymond]:
> Can I suggest that next() and __next__() be dropped entirely
> and that iterators just be made callable.
[GvR]
> This sounds attractive, except that I fear that
> the optimizations we've implemented for calling
> tp_next (especially for built-in iterators like
> list or dict itera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 2:07 PM, Ka-Ping Yee wrote:
> One possibility for making a next() built-in more useful:
>
> Just like getattr, two-argument next(iter, sentinel)
> returns sentinel if StopException is caught.
>
> If you've used .next() expli
One possibility for making a next() built-in more useful:
Just like getattr, two-argument next(iter, sentinel)
returns sentinel if StopException is caught.
If you've used .next() explicitly, would this be handy?
(Or, what convenience would you want in a next() builtin?)
-- ?!ng
___
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> At Guido's prompting, I drafted the following PEP. How does it sound?
>
> Title: Renaming iterator.next() to iterator.__next__()
> ==
It sounds and reads just fine, though I'm -1 on the change if onl
On 3/5/07, Christian Tanzer <[EMAIL PROTECTED]> wrote:
> FWIW, I always liked the `parameter passing is assignment` semantics
> of Python.
The parameter list is already so chock full of special cases (keyword
params, *varargs, **kwds, default values, and in Py3k required keyword
args and argument
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
> >>> def f(name, addr:tuple(street_num, street, city, state, zip)):
> ... street_num, street, city, state, zip = addr
Except that it won't work; annotations are evaluated at function
definition time, so street_num, street, city, state, zip
On 3/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> As an alternative, I propose that object grows a .next() method,
> which calls __next__ by default.
This would seem slated to confuse users; they will attempt to
implement next() instead of __next__(). Or people would attempt to
override th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 1:36 PM, Martin v. Löwis wrote:
> -1. I dislike the introduction of more builtins unless they have a
> true
> generality (i.e. are likely to be needed in many programs). For this
> one, I think the normal usage of __next__ will be
Ka-Ping Yee schrieb:
> The iterator protocol in Python 2.x consists of two methods:
> ``__iter__()`` called on an iterable object to yield an iterator, and
> ``next()`` called on an iterator object to yield the next item in the
> sequence. Using a ``for`` loop to iterate over an iterable object
>
Can I suggest that next() and __next__() be dropped entirely and that
iterators just be made callable. The current approach seems to make people
think there is something wrong with using an iterator directly (inside of in a
for-loop or function that consumes an iterator.
>>> ### What we do no
On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
[snip]
> Transition Plan
> ===
>
> Two additional transformations will be added to the 2to3 translation
> tool [2]_:
>
> * Method definitions named ``next`` will be renamed to ``__next__``.
>
> * Explicit calls to the ``next`` method
On 3/5/07, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > FWIW, I always liked the `parameter passing is assignment` semantics
> > of Python. I sure hope nobody is going to start a crus^H^H^H^HPEP to
> > remove tuple unpacking in general from the language!
> Isn't the point of this discussion that i
[EMAIL PROTECTED] wrote:
> > FWIW, I always liked the `parameter passing is assignment` semantics
> > of Python. I sure hope nobody is going to start a crus^H^H^H^HPEP to
> > remove tuple unpacking in general from the language!
>
> Isn't the point of this discussion that it is already gone?
AFAI
> FWIW, I always liked the `parameter passing is assignment` semantics
> of Python. I sure hope nobody is going to start a crus^H^H^H^HPEP to
> remove tuple unpacking in general from the language!
Isn't the point of this discussion that it is already gone?
___
At Guido's prompting, I drafted the following PEP. How does it sound?
-- ?!ng
Title: Renaming iterator.next() to iterator.__next__()
==
Abstract
The iterator protocol in Python 2.x consists of two methods:
``__iter__()`` called on
Ka-Ping Yee wrote:
> In summary, all of the arguments for removing this feature are of the
> form "It won't hurt very much if we remove the feature"; the arguments
> for keeping the feature are of the form "This feature is useful and
> good for the language." Notice the asymmetry: there are no arg
Ka-Ping Yee <[EMAIL PROTECTED]> wrote
> On 3/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > FWIW, I would like the feature to be kept. I've found it useful in that it
> > documents the function signature more completely when dealing
> > with arguments that are already pre-packed into tup
On 3/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, I would like the feature to be kept. I've found it useful in that it
> documents the function signature more completely when dealing
> with arguments that are already pre-packed into tuples
I just noticed that this has a more noticea
53 matches
Mail list logo
