Greg Ewing wrote:
> Brett C. wrote:
>
>> And before anyone decries the fact that this might confuse a newbie
>> (which
>> seems to happen with every advanced feature ever dreamed up), remember
>> this
>> will not be meant for a newbie but for someone
Guido van Rossum wrote:
> I've written a PEP about this topic. It's PEP 340: Anonymous Block
> Statements (http://python.org/peps/pep-0340.html).
>
> Some highlights:
>
> - temporarily sidestepping the syntax by proposing 'block' instead of 'with'
> - __next__() argument simplified to StopIterati
Nick Coghlan wrote:
> Brett C. wrote:
>
>> And while the thought is in my head, I think block statements should
>> be viewed
>> less as a tweaked version of a 'for' loop and more as an extension to
>> generators that happens to be very handy for resource ma
Guido van Rossum wrote:
> [Guido]
>
>>>An alternative that solves this would be to give __next__() a second
>>>argument, which is a bool that should be true when the first argument
>>>is an exception that should be raised. What do people think?
>>>
>>>I'll add this to the PEP as an alternative for
Guido van Rossum wrote:
[SNIP]
>>It's interesting that there is such similarity between 'for' and
>>'block'. Why is it that block does not call iter() on EXPR1? I
>>guess that fact that 'break' and 'return' work differently is a more
>>significant difference.
>
>
> Well, perhaps block *should*
Neil Schemenauer wrote:
> On Wed, Apr 27, 2005 at 03:58:14PM -0700, Guido van Rossum wrote:
>
>>Time to update the PEP; I'm pretty much settled on these semantics
>>now...
>
>
> [I'm trying to do a bit of Guido channeling here. I fear I may not
> be entirely successful.]
>
> The the __error__
Guido van Rossum wrote:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
>
> I'm +1 on accepting this now -- anybody against?
>
I'm +1. A couple of us discussed this at PyCon during the last day of the
sprints
Guido van Rossum wrote:
[SNIP]
> There's one alternative possible (still orthogonal to PEP 340):
> instead of __next__(), we could add an optional argument to the next()
> method, and forget about the next() built-in. This is more compatible
> (if less future-proof). Old iterators would raise an ex
Guido van Rossum wrote:
> [Ka-Ping Yee]
>
>>It occurred to me as i was messing around with handling and re-raising
>>exceptions that tossing around these (type, value, traceback) triples
>>is irritating and error-prone.
>>
>>How about just passing around a single value? All we'd have to do is
>>p
Guido van Rossum wrote:
> [Ka-Ping Yee]
>
>>Suppose exceptions have an optional "context" attribute, which is
>>set when the exception is raised in the context of handling another
>>exception. Thus:
>>
>>def a():
>>try:
>>raise AError
>>except:
>>raise
Guido van Rossum wrote:
[SNIP]
> Straight up-or-down votes in the full senate are appreciated at this point.
>
PEP 340 redux gets my +1; I think using generators will become more obviously
useful to people when, as Fredrick pointed out, your code grows more than a few
lines long.
> On to the sec
Guido van Rossum wrote:
> [Brett C.]
>
>>Seems like, especially if we require inheritance from a base exception class
>>in
>>Python 3000, exceptions should have standard 'arg' and 'traceback' attributes
>>with a possible 'context' attri
Guido van Rossum wrote:
> [Ka-Ping Yee]
>
>>Maybe bare 'except' should be spelled 'except *'.
>
>
> -1.
>
>
>>I don't think it can be removed altogether because sometimes you just
>>need to be able to do magic, but it can be made a little more explicit.
>
>
> Assuming a single root of the ex
Guido van Rossum wrote:
> [Guido]
>
>>>What if that method catches that exception?
>
>
> [Ka-Ping Yee]
>
>>Did you mean something like this?
>>
>>def handle():
>>try:
>>open('spamspamspam')
>>except:
>>catchit()
>># point A
>>.
Guido van Rossum wrote:
> [Brett C.]
>
>>Maybe, but as long as caught exceptions get cleared that should be an issue.
>>Would this be solved if, when an 'except' branch is exited, exceptions are
>>cleared? So, in the above example, once the 'pass' is h
Guido van Rossum wrote:
> [Fredrik Lundh]
>
>>intuitively, I'm -1 on this proposal.
>
Just to toss in my opinion, I prefer PEP 340 over 343 as well, but not so much
to give 343 a -1 from me.
[SNIP - question of how to handle argument against 340 being a loop which I
never totally got since you
Paul Moore wrote:
> On 5/14/05, Brett C. <[EMAIL PROTECTED]> wrote:
>
>>Nick's was obviously directly against looping, but, with no offense to Nick,
>>how many other people were against it looping? It never felt like it was a
>>screaming mass with pitchforks bu
Guido van Rossum wrote:
[SNIP - bunch of points from Guido]
> Do we really need both __context__ and __cause__? Methinks that you
> only ever need one: either you explicitly chain a new exception to a
> cause, and then the context is probably the same or irrelevant, or you
> don't explicitly chain
st thing I want happening is people finding mistakes in the code. =) But if
enough people request the source I will take the time to generate a tar.bz2
file of patches against the 2.3.4 source release and put them up somewhere.
Below is the abstract culled directly from the thesis it
Armin Rigo wrote:
> Hi Brett,
>
> On Tue, May 24, 2005 at 04:11:34PM -0700, Brett C. wrote:
>
>>My thesis, "Localized Type Inference of Atomic Types in Python", was
>>successfully defended today for my MS in Computer Science at the California
>>Polyt
Reinhold Birkenfeld wrote:
> Hello,
>
> would anybody mind if I was given permissions on the tracker and CVS, for
> fixing small
> things like bug #1202475. I feel that I can help you others out a bit with
> this and
> I promise I won't change the interpreter to accept braces...
>
Since no dir
Been rather quite around here lately so I just wanted to do a quick check to
see what the status is on PEPs 342 and 343. I noticed Nick's PEP is still not
up. Probably too busy with that fix for genexps in the AST branch, huh, Nick?
=)
Guido, you need something hashed out from us at this point
Nick Coghlan wrote:
> Nick Coghlan wrote:
>
>>Brett C. wrote:
>>
>>
>>>I noticed Nick's PEP is still not
>>>up. Probably too busy with that fix for genexps in the AST branch, huh,
>>>Nick? =)
>>
>>Something like that. . . st
Facundo Batista wrote:
> Going on with the old bugs checking, here are the results for 2.2.2 (and
> one from 2.2.1). When I'll finish this will be put in an informational PEP.
>
Great work, Facundo! Now I feel lazy. =)
-Brett
___
Python-Dev mailing l
Facundo Batista wrote:
> On 5/30/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>
>
>>While we can't (and shouldn't) delete categories, we can change the text used
>>to describe them. So "Python 2.2.2" can become "Python 2.2.2
>>(unmaintained)". Whether this is desirable or not, I'm not sure
Gregory P. Smith wrote:
[SNIP]
> major gripe to -dev: a 'make install' of the full cvs tree should not
> be required to test that some changes to existing .py files that pass
> their tests (in this case they -are- the tests) are ok to check in.
>
You actually don't have to. If you execute the in
Guido van Rossum wrote:
[SNIP - Guido already said throw() is the name to be used]
> - Whether and how to keep a door open for a future extension to the
> syntax that allows multiple resources to be acquired in a single
> with-statement. Possible syntax could be
>
> (a)with EXPR1 [as VAR1], EX
101 - 127 of 127 matches
Mail list logo
