"Collin Winter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| >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 ne
Guido van Rossum wrote:
> ValueError is
> typically a bug in the immediate code containing the call.
Not necessarily, because the value may have been
stored somewhere for a while before being used.
> IOError is
> something that could happen even to valid calls (e.g. when a library
> is passed a s
Daniel Stutzbach wrote:
> An IOError makes it more clear
> that something went awry, while a ValueError typically implies that
> the operation was rejected altogether.
In the code I typically write, the IOError will get
reported to the user, who won't know why it happened
or what to do about it, a
Ka-Ping Yee schrieb:
> 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
While reviewing the patch for __dir__() (which I'll apply then, since it was
generally agreed upon at least for Py3k), I came about this:
/* Merge in __members__ and __methods__ (if any).
XXX Would like this to go away someday; for now, it's
XXX needed to get at im_self etc of method objec
Guido van Rossum wrote:
> 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
> > Because unittest always creates **kwargs, any code path in a C
> > function which is only executed when the *keywords parameter is NULL
> > will never be correctly tested from the standard unittest methods.
>
> This needs some context; which call from unittest to a C function are
> you talking
On 3/7/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Collin Winter" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | >From the checked-in version,
> |
> | """
> | Two additional transformations will be added to the 2to3 translation tool
> [3]:
> |
> |* Method definitions name
I don't agree with this line of reasoning. It should be a ValueError
when passing a nonblocking raw I/O object to BufferedIO, but that's
not detectable (at least not without an unpleasant amount of
platform-specific code), and it isn't sufficient either, since the
file could be blocking initially a
On 3/7/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> > > Because unittest always creates **kwargs, any code path in a C
> > > function which is only executed when the *keywords parameter is NULL
> > > will never be correctly tested from the standard unittest methods.
> >
> > This needs some conte
On Tue, 6 Mar 2007, Collin Winter wrote:
> I can give you warnings on the following items,
> - global assignments to "next".
> - global definitions of a "next" function.
> - global imports of anything named "next".
> - assignments to "__builtin__.next".
How hard would it be to warn about any ass
On 3/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Mar 2007, Collin Winter wrote:
>
> > I can give you warnings on the following items,
>
> > - global assignments to "next".
> > - global definitions of a "next" function.
> > - global imports of anything named "next".
> > - assignments to
On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think maybe a useful simplification would be to support special
> return values to capture EWOULDBLOCK (or equivalent) in the raw I/O
> interface only.
That makes sense.
> The buffering layer could then raise IOError (or perhaps a special
On 3/7/07, Jim Jewett <[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;
>
> Is this a "could", or "should"? I would expect the buffering layer
> (particularly output) to use its buf
I don't recall ripping them out, but it's worth trying to do that --
they really shouldn't be needed for modern extensionmodules (2.2+).
On 3/7/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> While reviewing the patch for __dir__() (which I'll apply then, since it was
> generally agreed upon at leas
On 3/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I think maybe a useful simplification would be to support special
> > return values to capture EWOULDBLOCK (or equivalent) in the raw I/O
> > interface only.
>
> That makes sense.
>
> > The
On 7/13/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > It turns out I was misled by Collin's claim that the PEP wants
> > > isCallable and sequenceIncludes removed "because there are
On 3/7/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee schrieb:
> > 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
Nick Coghlan wrote:
> One of the comments made on Georg's initial attempt at implementing
> these features was that it would be nice to avoid the function call
> overhead in the listcomp & setcomp case ... I tried to do that and
> essentially failed outright
Not having seen the code, my though
Since next() is equivalent to send(None) we don't really need the
next() method do we?
On 3/7/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/7/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Ka-Ping Yee schrieb:
> > > On Wed, 7 Mar 2007, Georg Brandl wrote:
> > >> Ka-Ping Yee schrieb:
> > >> >
On 3/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > How about determining if it's a *simple* case or not, and doing the
> > variable renaming in the simple case and Georg's original version in
> > non-simple cases? You can define "simple" as whatever makes the
> > determination easy and still tr
Jim Jewett wrote:
> Is this a "could", or "should"? I would expect the buffering layer
> (particularly output) to use its buffer, and to appear blocking
> (through sleep-and-retry) when that isn't enough.
No! Busy waiting should *not* be done implicitly.
--
Greg
On 3/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Since next() is equivalent to send(None) we don't really need the
> next() method do we?
>
Guess not, especially if we make send() default to sending None back.
-Brett
> On 3/7/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 3/7/07, Geo
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Since next() is equivalent to send(None) we don't really need the
> next() method do we?
As long as its renamed to __next__, then we seemingly wouldn't need next,
though users needing to use next(X) or X.send(None) instead of X.next(),
may be confus
On 3/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 7/13/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 7/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > On 7/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > It turns out I was misled by Collin's claim that the PEP wants
> >
Going back in this list, I see a number of issues which were discussed
at length, but there is no corresponding PEP. I realize that in some
cases, this is because no actual consensus was reached.
In any case, I would like to know, what is the current status of the
following issues:
-- Gener
I don't think a consensus has been reached on any of these.
My votes:
- generic functions: no
- interfaces: no, but I'd like to work on ABCs instead
- metaclass syntax: I'd like to see your PEP
--Guido
On 3/7/07, Talin <[EMAIL PROTECTED]> wrote:
> Going back in this list, I see a number of issu
Guido van Rossum wrote:
> I don't think a consensus has been reached on any of these.
>
> My votes:
>
> - generic functions: no
Here's how I would summarize the current state of generic functions.
Function decorators + argument decorators already provide everything
needed for a third-party dev
28 matches
Mail list logo
