Guido van Rossum wrote:
> [Fredrik Lundh]
>
>>unlike the original design, all you get from this is
>>the ability to add try/finally blocks to your code
>>without ever writing a try/finally-clause (neither
>>in your code or in the block controller). that
>>doesn't strike me as especially pythonic.
Hey all-
Simple question. I'm working on getting Python support enabled for the Gimp
under Win32. I've set up and successfully compiled the Gimp under a MSYS/MinGW
enviroment, using both python.org Python 2.3 and ActivePython 2.3 (I need to
stick to 2.3 due to support issues with the packaging
Nick Coghlan wrote:
> That would be good, in my opinion. I updated PEP 3XX to use this idea:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>
> With that update (to version 1.6), PEP 3XX is basically PEP 343, but
> injecting
> exceptions that occur into the template generator's inte
Shane Hathaway wrote:
> Here is example A, a non-looping block statement using "try":
>
> text = 'diamond'
> for fn in filenames:
> try opening(fn) as f:
> if text in f.read():
> print 'I found the text in %s' % fn
> break
That's a pretty
Ka-Ping Yee wrote:
> - The generator style in PEP 340 is the easiest to compose and
> reuse, but its implementation is the most complex to understand.
The latest version of my PEP 3XX aims to get (most of) the power of PEP 340,
with the easy comprehensibility of PEP 310. What magic it requi
Shane Hathaway wrote:
> Guido van Rossum wrote:
> >
> > Consider an application where you have to acquire *two* locks regularly:
> >
> You really have to write it like this:
Shane, you've already solved this one more elegantly:
def lockBoth():
return combining(lock1.locking(), lock2.locking()
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 but more of a "I don't love it, but I can deal"
> crowd.
Agr
On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>From there I see the semantics:
VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
exc = (None, None, None)
try:
try:
BLOCK1
except:
exc = sys.exc_info()
fin
"Steve Castellotti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Simple question. I'm working on getting Python [2.3] support enabled
> for the Gimp under Win32.
...
>Am I missing something obvious? Is this a question better suited to
> MinGW/MSYS mailing lists, or perhaps
Shane Hathaway <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
> > That would be good, in my opinion. I updated PEP 3XX to use this idea:
> > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> >
> > With that update (to version 1.6), PEP 3XX is basically PEP 343, but
> > injecting
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 but more of a "I don't love it, but I
On 5/15/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> There were a *lot* of nice features with PEP 340. The initial
> discussion had a lot of people enthusiastic about all the neat things
> they could do with it. That's disappeared now, in a long series of
> attempts to "fix" the looping issue.
Havi
Steven Bethard wrote:
> On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>
>
>>From there I see the semantics:
>
> VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
> exc = (None, None, None)
> try:
> try:
> BLOCK1
Paul Moore wrote:
> Looping is definitely a wart. Looping may even be a real problem in
> some cases. There may be cases where an explicit try...finally remains
> better, simply to avoid an unwanted looping behaviour.
I agree PEP 343 throws away too much that was good about PEP 340 - that's why
I
On Sun, 15 May 2005, Shane Hathaway wrote:
> You might add to the PEP the following example, which could really
> improve the process of building GUIs in Python:
>
> class MyFrame(Frame):
> def __init__(self):
> with Panel():
> with VerticalBoxSizer():
>
Shane Hathaway wrote:
> PEP 340 is very nice, but it became less appealing to me when I saw
> what it would do to "break" and "continue" statements.
Absolutely. I really liked PEP 340, but two things stood out to me as
being flawed:
1. Looping - it took a while for me to realise this was buggin
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Sun, 15 May 2005, Shane Hathaway wrote:
> > You might add to the PEP the following example, which could really
> > improve the process of building GUIs in Python:
> >
> > class MyFrame(Frame):
> > def __init__(self):
> > with P
[Nick Coghlan]
> > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
[Steven Bethard]
> there I see the semantics:
>
> VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
> exc = (None, None, None)
> try:
> try:
> BLOCK1
> except:
> exc = sys.exc_info()
> finally
At 08:18 AM 5/16/2005 +1000, Nick Coghlan wrote:
>Paul Moore wrote:
> > Looping is definitely a wart. Looping may even be a real problem in
> > some cases. There may be cases where an explicit try...finally remains
> > better, simply to avoid an unwanted looping behaviour.
>
>I agree PEP 343 throws
Ka-Ping Yee wrote:
> On Sun, 15 May 2005, Shane Hathaway wrote:
>
>>You might add to the PEP the following example, which could really
>>improve the process of building GUIs in Python:
>>
>>class MyFrame(Frame):
>>def __init__(self):
>>with Panel():
>>with V
It's been interesting watching all the loops this discussion has gone
through. I'm not sure the following is compatible with the current
proposals, but maybe it will spur some ideas or help rule out something.
There have been several examples of problems with opening several
resources inside
Guido van Rossum wrote:
> [...] But some of the claims from PEP 3XX seem to be incorrect now: Nick
> claims that a with-statement can abstract an except clause, but that's
> not the case; [...]
Sorry for being a lurker, but can I try and expand this point.
The options:
- If we don't allow the ex
Phillip J. Eby wrote:
> This makes it seem awkward for e.g. "do self.__lock", which doesn't
> make any sense. But the extra call needed to make it "do
> locking(self.__lock)" seems sort of gratuitous.
How about
do holding(self.__lock):
...
> It makes me wonder if "with" or "using" or
Guido van Rossum wrote:
>>Also, one question: will the "do protocol" be added to built-in "resource"
>>types? That is, locks, files, sockets, and so on?
>
> One person proposed that and it was shot down by Greg Ewing. I think
> it's better to require a separate wrapper.
It depends on whether th
A additional comment (or 2) on my previous message before I go back to
lurk mode.
If the recommended use of each resource template is kept to a single
resource, then each enter and exit can be considered a whole block of
code that will either pass or fail. You can then simplify the previous
t
Fredrik Lundh wrote:
> try with opening(file) as f:
> body
> except IOError:
> deal with the error (you have to do this anyway)
You don't usually want to do it right *there*, though.
More likely you'll have something further up that deals
with a variety of possible errors.
On Sun, 15 May 2005, Guido van Rossum wrote:
> In rev 1.10 I moved the __enter__ call out of the
> try-block again. Having it inside was insane: when __enter__ fails, it
> should do its own cleanup rather than expecting __exit__ to clean up
> after a partial __enter__.
No, it wasn't insane. You h
On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
In reading over PEP 3XX again, it struck me that I'd been having a
really hard time grasping exactly when I needed to use the
"needs_finish" decorator. Am I right in saying that I shoul
Steven Bethard wrote:
> If I've misunderstood, and there are other situations when
> "needs_finish" is required, it'd be nice to see some more examples.
The other cases are where you want to do something in response to an
exception, but not otherwise::
def gen():
try:
yie
Guido van Rossum wrote:
> But then the reason for separating VAR from EXPR becomes unclear.
> Several people have mentioned that they thought this was "a good idea
> on its own", but without giving additional use cases. Without the
> ability to write the acquire/release template as a generator, th
Nick Coghlan wrote:
> The naming convention for 'do' is shown in the current PEP 343. The issue
> I've
> noticed with it is that *functions* read well, but methods don't because
> things
> get out of sequence. That is, "do locking(the_lock)" reads well, but "do
> the_lock.locking()" does not.
Guido van Rossum wrote:
> PEP 340 is still my favorite, but it seems there's too much opposition
> to it,
I'm not opposed to PEP 340 in principle, but the
ramifications seemed to be getting extraordinarily
complicated, and it seems to be hamstrung by
various backwards-compatibility constraints.
E
Brett C. 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 but more of a "I don't love it, but I can deal"
> crowd.
My problem with looping was that,
33 matches
Mail list logo
