Phillip J. Eby wrote:
> At 07:47 AM 1/10/2007 -0800, Guido van Rossum wrote:
>> BTW perhaps we should add the same semantics and syntax to 'with expr
>> as var'? I can't think of a reasonable use case
> [snip]
>> ... for using anything
>> more complex than a local variable, BTW.)
>
> with multi(ct
At 12:37 AM 1/12/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>At 07:47 AM 1/10/2007 -0800, Guido van Rossum wrote:
>>>BTW perhaps we should add the same semantics and syntax to 'with expr
>>>as var'? I can't think of a reasonable use case
>>[snip]
>>>... for using anything
>>>more compl
Let me clarify. I have no desire to prevent tuple assignment in with
statements. But I do think that the tuples could be limited to plain
names and other tuples (with similar constraints), and those names
should all be zapped at the end of the clause, like for except. And we
don't even have to add
At 08:36 AM 1/11/2007 -0800, Guido van Rossum wrote:
>Let me clarify. I have no desire to prevent tuple assignment in with
>statements. But I do think that the tuples could be limited to plain
>names and other tuples (with similar constraints), and those names
>should all be zapped at the end of th
The case for changing 'for' is weakest, for sure. But 'with' is easy
to coerce into the same category as 'import' and 'except' since it
already uses 'as'...
On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:36 AM 1/11/2007 -0800, Guido van Rossum wrote:
> >Let me clarify. I have no des
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The case for changing 'for' is weakest, for sure.
As I understand the proposal, the rationale for restricting the exception
target is the autodeletion, which is obviously bug-prone if applied to
pre-existing struc
At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
>Yes, I already see it that way. It would be nice if the rule for 'as'
>targets were as consistent as possible (ie, at least the same for except
>and with)
No can do - with needs tuples, except isn't getting them.
If we did allow tuples in both cas
On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
> >Yes, I already see it that way. It would be nice if the rule for 'as'
> >targets were as consistent as possible (ie, at least the same for except
> >and with)
>
> No can do - with needs tuple
At 03:42 PM 1/11/2007 -0600, Collin Winter wrote:
>On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
>> >Yes, I already see it that way. It would be nice if the rule for 'as'
>> >targets were as consistent as possible (ie, at least the same for
On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:42 PM 1/11/2007 -0600, Collin Winter wrote:
> >On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
> >> >Yes, I already see it that way. It would be nice if the rule for 'as'
> >> >t
Guido van Rossum wrote:
> On 1/11/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I thinking that the 3.0.X version be considered a try it out (alpha) release
>> to
>> generate plenty of feed back, and the 3.1.X version be the first version
>> meant
>> for actual development use.
I did list "plenty
On Tue, Jan 09, 2007, Brett Cannon wrote:
> On 1/9/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>> On 1/5/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>> Obsolete
>>>
>>>
>>> Becoming obsolete signifies that either another module in the stdlib
>>> or a widely distributed third-party librar
I've just posted my first pass of the full "lazy strings" patch, with
both "lazy concatenation" and "lazy slices". It's available on
Sourceforge here:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1629305&group_id=5470
It applies cleanly (with "patch -p1") against the curren
<"Anthony Baxter">
> Comments? What else should get warnings?
It is my strong preference that we not go down this path.
Instead, the 2.6 vs 3.0 difference analysis should go in an
external lint utility.
The Py2.x series may live-on for some time and should do so
as if Py3.x did not exist. Bur
Raymond Hettinger wrote:
> Also, I'm wondering if the desire for 2.6 warnings is based on the notion that
> it will be possible to get large tools to work under both Py2.x and Py3.x.
I had certainly assumed it would be possible.
In fact, I had assumed that the 2->3 translator would have a mode
w
Jim Jewett wrote:
> Raymond Hettinger wrote:
>
>> Also, I'm wondering if the desire for 2.6 warnings is based on the notion
>> that
>> it will be possible to get large tools to work under both Py2.x and Py3.x.
>
> I had certainly assumed it would be possible.
>
> In fact, I had assumed that the
On 1/11/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > Raymond Hettinger wrote:
> >
> >> Also, I'm wondering if the desire for 2.6 warnings is based on the notion
> >> that
> >> it will be possible to get large tools to work under both Py2.x and Py3.x.
> >
> > I had certainly assu
17 matches
Mail list logo
