Greg Ewing schrieb:
> 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() would do.
Not all of them. operator
On 3/6/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
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
>
Terry Reedy schrieb:
> On the consistency argument: sorted(somelist) calls copy(somelist).sort,
> not copy(somelist).__sort__.
Actually, it calls list(somelist).sort, so it requires iteration, not
copying, and the result will be known to be a list. So the important
difference is that .sort is
Raymond Hettinger schrieb:
>> 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(s
Patrick Maupin schrieb:
> 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).
You should turn the question then around: "This is what I want t
Patch http://python.org/sf/1673355 changes Ellipsis' repr() to '...'. While
this is consistent, the submitter himself noted that it would probably cause
problems with doctest.
Additionally, '...' is currently used to denote recursive structures in the
repr of lists and dicts, so this would have to
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
Patch http://python.org/sf/1673355 changes Ellipsis' repr() to '...'.
While
this is consistent, the submitter himself noted that it would probably
cause
problems with doctest.
Additionally, '...' is currently used to denote recursive structures
On 3/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Patrick Maupin schrieb:
> > 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).
>
Georg and I have been working on the implementation of list
comprehensions which don't leak their iteration variables, along with
the implementation of set comprehensions. The latest patch can be found
as SF patch #1660500 [1]. The file new-set-comps.diff is the combined
patch which implements
On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> In fact, your example was specifically anticipated and addressed in
> the PEP draft I posted here. file.read() is not invoked by a language
> construct. When file.read() gets called, it is because the calling
> code has an explicit call to read(
Nick Coghlan schrieb:
> Georg and I have been working on the implementation of list
> comprehensions which don't leak their iteration variables, along with
> the implementation of set comprehensions. The latest patch can be found
> as SF patch #1660500 [1]. The file new-set-comps.diff is the com
On 3/5/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> 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
I've rejected it.
On 3/6/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Patch http://python.org/sf/1673355 changes Ellipsis' repr() to '...'.
> While
> > this is consistent, the submitter himself noted that it would probably
> cause
> > p
Aahz schrieb:
> On Tue, Mar 06, 2007, Andrew Dalke wrote:
>> On 3/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>>
>>> I don't know too many good use cases for
>>> locals() apart from "learning about the implementation" I think this
>>> might be okay.
>>
>> Since I'm watching this list for an
Patrick Maupin schrieb:
> That was a statement. The question comes later :)
>
>> This seems the tricky part here: What *is* it that you want to
>> display?
>
> The obvious, greenfield, blue-sky, non-pre-existing-implementation,
> perfect-world thing to do is to add a record to the stack tracebac
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> While we're at it: I've had a thought about string formatting in Py3k.
> Suppose you do something like
>
> name = "He"
> what = "Ex-Parrot"
> print "{name} is an {what}".format(name=name, what=what)
>
> it seems a bit too verbose. Why not have fo
Quick responses from just reading the email (I'll try to review the
code later today, I'm trying to do Py3k work all day):
On 3/6/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Georg and I have been working on the implementation of list
> comprehensions which don't leak their iteration variables, a
On 3/5/07, Greg Ewing <[EMAIL PROTECTED]> 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 have made things neater. Just about any place
Having now read this entire thread I am going to accept Ping's PEP.
Adding the sentinel argument to the next() builtin was what did it for
me: it neatly solves the problem if having to catch that StopIteration
in 99% of the cases.
Thanks all for the discussion!
--Guido
On 3/6/07, Guido van Rossu
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> While we're at it: I've had a thought about string formatting in Py3k.
> Suppose you do something like
>
> name = "He"
> what = "Ex-Parrot"
> print "{name} is an {what}".format(name=name, what=what)
>
> it seems a bit too verbose. Why not have fo
Patrick, I would recommend not to worry about that just yet. As a
first cut it's quite alright if a traceback in the formatter is just
passed through by the format() call without adding any indication of
where in the format string it happened. There are tons of ways to
debug that.
--Guido
On 3/6/
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Having now read this entire thread I am going to accept Ping's PEP.
> Adding the sentinel argument to the next() builtin was what did it for
> me: it neatly solves the problem if having to catch that StopIteration
> in 99% of the cases.
Have you rea
Actually, the version checked in to
http://svn.python.org/projects/sandbox/trunk/pep3101 currently will
search both locals() and globals() if no parameters are passed to
format.
It's still a work-in-progress, but has quite a few passing tests, and
builds as an extension module on 2.3, 2.4, and 3.0
EIBTI, it's true, but in some cases it's awfully handy to be implicit.
Ian Bicking and I were tossing this around, and came up with some
ideas, all of which are certainly flawed in one way or another :)
One idea is that an additional string formatting method which will
automatically work with loc
I don't see much point of adding the builtin if we don't rename the
method to __next__, since that would just make the wart stick out
more. The conversion pain is a one-time cost. We can work with 2to3
and Python 2.6 warnings on the conversions. Hey, if we can "from
__future__ import dict_views" th
Guido van Rossum schrieb:
Having now read this entire thread I am going to accept Ping's PEP.
Adding the sentinel argument to the next() builtin was what did it for
me: it neatly solves the problem if having to catch that StopIteration
in 99% of the cases.
Attached is a possible implementation
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Having now read this entire thread I am going to accept Ping's PEP.
> > Adding the sentinel argument to the next() builtin was what did it for
> > me: it neatly solves the problem if having to catch that StopIteratio
On 3/6/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> http://docs.python.org/dev/api/type-structs.html#l2h-1017 doesn't say
> that a NULL return can be used as a signal that iterator is exhausted
> without raising StopIteration. That would mean the above could be
> simplified somewhat in terms of r
On 3/6/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum schrieb:
> > > Having now read this entire thread I am going to accept Ping's PEP.
> > > Adding the sentinel argument to the next() builtin was what did it for
> > > me: it n
Patrick Maupin wrote:
> I'm not sure that I can
> legitimately add to a preexisting traceback from a C function in a
> non-fragile fashion.
Pyrex does this by creating a fake stack frame and
filling most of it in with dummy values. It can be
done, but it's ugly. Let me know if you're interested
an
Reading this and all the other discussion on the proper semantics for
non-blocking I/O I think I may have overreached in trying to support
non-blocking I/O at all levels of the new I/O stack. There probably
aren't enough use cases for wanting to support readline() returning
None if no full line if
On Tue, 6 Mar 2007, Guido van Rossum wrote:
> Having now read this entire thread I am going to accept Ping's PEP.
> Adding the sentinel argument to the next() builtin was what did it for
> me: it neatly solves the problem if having to catch that StopIteration
> in 99% of the cases.
Okay, this is c
Ka-Ping Yee wrote:
> Okay, this is checked in as PEP 3114.
Not 3456? :-(
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/ar
Ka-Ping Yee schrieb:
> On Tue, 6 Mar 2007, Guido van Rossum wrote:
>> Having now read this entire thread I am going to accept Ping's PEP.
>> Adding the sentinel argument to the next() builtin was what did it for
>> me: it neatly solves the problem if having to catch that StopIteration
>> in 99% of
On Wed, 7 Mar 2007, Georg Brandl wrote:
> Ka-Ping Yee schrieb:
> > On Tue, 6 Mar 2007, Guido van Rossum wrote:
> >> Having now read this entire thread I am going to accept Ping's PEP.
> >> Adding the sentinel argument to the next() builtin was what did it for
> >> me: it neatly solves the problem i
>From the checked-in version,
"""
Two additional transformations will be added to the 2to3 translation tool [3]:
* Method definitions named next will be renamed to __next__.
* Explicit calls to the next method will be replaced with calls to
the built-in next function. For example, x.next(
+1
I liked the original design at first, but after fleshing it and out
and seeing all of the corner cases raised here, the Buffered I/O
interface for non-blocking would have to be so different that it would
not make much sense to make it the same type.
The raw I/O layer semantics are unchanged, r
On 3/6/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> +1
>
> I liked the original design at first, but after fleshing it and out
> and seeing all of the corner cases raised here, the Buffered I/O
> interface for non-blocking would have to be so different that it would
> not make much sense to ma
On 2/28/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Travis Oliphant <[EMAIL PROTECTED]> wrote:
> > Josiah Carlson wrote:
> > >Travis Oliphant <[EMAIL PROTECTED]> wrote:
> > >>I think you are right. In the discussions for unifying string/unicode I
> > >>really like the proposals that are lean
Guido van Rossum wrote:
> Would this satisfy the critics of the current design?
That all sounds reasonable to me.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.
On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The buffering layer could then raise IOError (or perhaps a special
> subclass of it) if the raw I/O layer ever returned one of these;
What's the rationale for IOError instead of ValueError? Isn't it an
error in the application to apply the
On Tue, 6 Mar 2007, Collin Winter wrote:
> I'd like to strike the part about making "x.next()" ->
> "next(x)"/"x.__next__()" determined by the presence of a module-level
> "next" binding. I'd rather see the transformation always be "x.next()"
> -> "next(x)" and warn on top-level "next"s. Doing it t
On 3/6/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The buffering layer could then raise IOError (or perhaps a special
> > subclass of it) if the raw I/O layer ever returned one of these;
>
> What's the rationale for IOError instead of Value
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I haven't been following that as closely as perhaps I should have. I'd
> be glad to drop this and go back to a string
> representation/implementation that's essentially the 2.x unicode type,
> with a compile-time configuration choice between 16 or 32
On 3/6/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> What's the rationale for IOError instead of ValueError? Isn't it an
> error in the application to apply the buffering layer to a
> non-blocking socket, and not something related to a connection reset?
The buffering layer can't easily detect that
It appears that if a C function is called from Python with **kwargs, a
new dictionary object is created and passed to the C function even if
**kwargs is empty, but if the same C function is called without
**kwargs, then the NULL pointer is passed to the C function.
Because unittest always creates
On 3/6/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> It appears that if a C function is called from Python with **kwargs, a
> new dictionary object is created and passed to the C function even if
> **kwargs is empty, but if the same C function is called without
> **kwargs, then the NULL pointer i
Adam Olsen wrote:
> What's the rationale for IOError instead of ValueError? Isn't it an
> error in the application to apply the buffering layer to a
> non-blocking socket, and not something related to a connection reset?
Good point -- I often put a try-except for EnvironmentError
around things t
48 matches
Mail list logo
