Greg Ewing wrote:
> Nick Coghlan wrote:
>> Hmm, with that approach, a code inspection tool like pychecker could
>> be used to pick up the slack, and flag generators which have a yield
>> inside a try/finally or a user defined statement without applying
>> the "needs finalisation" decorator
>
> W
Nick Coghlan wrote:
> Hmm, with that approach, a code inspection tool like pychecker could be used
> to
> pick up the slack, and flag generators which have a yield inside a
> try/finally
> or a user defined statement without applying the "needs finalisation"
> decorator
What about giving the
Guido van Rossum wrote:
> Now it would make more sense to change the syntax to
>
> with EXPR as VAR:
> BLOCK
>
> and we have Phillip Eby's proposal.
Change the 'with' to 'do' and I'd be +1 on this.
--
Greg Ewing, Computer Science Dept, +
Patch / Bug Summary
___
Patches : 332 open (+10) / 2834 closed ( +2) / 3166 total (+12)
Bugs: 927 open ( +7) / 4959 closed ( +7) / 5886 total (+14)
RFE : 186 open ( +0) / 157 closed ( +1) / 343 total ( +1)
New / Reopened Patches
__
Feature e
[Timothy Fitz]
> A more flexible approach would be to allow finally at the beginning or
> ending of the try statement. A more flexible approach would be to
> allow both, or even finally clauses mixed in.
-1000.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Hello,
While investigating why the script used in http://docs.freebsd.org/
cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much
system time on FreeBSD 5, I noticed that python is continually
calling sigprocmask(), as can be seen from the following ktrace(1) dump:
673 python
On May 10, 2005, at 2:48 PM, Nicholas Bastin wrote:
> On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote:
>
>
>>> Wow, what an inane way of looking at it. I don't know what world
>>> you
>>> live in, but in my world, users read the configure options and
>>> suppose
>>> that they mean somethin
> No, as except clauses can only occur before the finally clause, and execution
> should not go backwards.
This restriction feels a bit arbitrary. I can guarantee someone is
going to flatten this:
try:
try:
A
finally:
B
except IOError:
C
A more flexible approach would
Nicholas Bastin wrote:
> I'm perfectly happy to continue supporting --enable-unicode=ucs2, but
> not displaying it as an option. Is that acceptable to you?
It is. Somewhere, the code should say that this is for backwards
compatibility, of course (so people won't remove it too easily;
if there is
M.-A. Lemburg wrote:
> If all you're interested in is the lexical class of the code points
> in a string, you could use such a codec to map each code point
> to a code point representing the lexical class.
How can I efficiently implement such a codec? The whole point is doing
that in pure Python (
On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote:
>> Wow, what an inane way of looking at it. I don't know what world you
>> live in, but in my world, users read the configure options and suppose
>> that they mean something. In fact, they *have* to go off on their own
>> to assume something,
M.-A. Lemburg wrote:
> Martin, please reconsider... the choice is between:
The point is that this all was discussed, and decided the
other way 'round. There is no point in going back and forth
between the two choices:
http://mail.python.org/pipermail/python-dev/2003-June/036461.html
If we remove
At 08:51 AM 5/10/2005 -0700, Guido van Rossum wrote:
>[Phillip J. Eby]
> > Yeah, I'd ideally like to see __try__, __except__, __else__, and
> > __finally__ methods, matching the respective semantics of those clauses in
> > a try/except/finally block.
>
>What's your use case for adding this complexi
Nick Coghlan wrote:
> Draft 1.3 of my PEP 310/PEP 340 merger is now up for public consumption:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
This draft was meant to drop the idea of __enter__() raising TerminateBlock
preventing execution of the statement body. I dropped it out of th
Guido van Rossum wrote:
> [Nick]
> Is that use case strong enough to require the added complexity? For a
> transactional wrapper, I can see that __exit__ needs to know about
> exceptions (though I'm unsure how much detail it needs), but what's
> the point of being able to tell an exception from a n
[Phillip J. Eby]
> Yeah, I'd ideally like to see __try__, __except__, __else__, and
> __finally__ methods, matching the respective semantics of those clauses in
> a try/except/finally block.
What's your use case for adding this complexity? I'm going for simple
here unless there's a really strong u
Guido van Rossum wrote:
> I used to dislike this, but the opposition and the proliferation of
> alternative proposals have made me realize that I'd rather have this
> (plus "continue EXPR" which will be moved to a separate PEP once I
> have some extra time) than most of the other proposals.
Draft
[Alex]
> I like this. The only aspect of other proposals that I would sorely
> miss here, would be the inability for abc.__exit__ to deal with
> exceptions raised in BLOCK (or, even better, a separate specialmethod
> on abc called in lieu of __exit__ upon exceptions). Or am I missing
> something,
At 07:57 AM 5/10/2005 -0700, Alex Martelli wrote:
>On May 9, 2005, at 21:58, Guido van Rossum wrote:
> > But what if we changed the translation slightly so that VAR gets
> > assigned to value of the __enter__() call:
> >
> > abc = EXPR
> > VAR = abc.__enter__() # I don't see wh
[Nick]
> The User Defined Statement section of my PEP redraft suggests something very
> similar to this:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>
> It suggests more complex semantics, so that the statement template has the
> chance to intercept exceptions raised in the block,
On May 9, 2005, at 21:58, Guido van Rossum wrote:
> Apologies if this has been discovered and rejected already; I've had
> to skip most of the discussions but this though won't leave my head...
Skimming rather than skipping all of the discussion burned most of my
py-dev time, and it was just s
On 5/10/05, Michele Simionato <[EMAIL PROTECTED]> wrote:
>
> Well, actually I am even more ambitious than that: not only I would like
> to be able to copy functions, but I also would like to be able to subclass
> FunctionType with an user-defined __copy__ method.
BTW, it seems possible to copy c
On 5/9/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Choices:
> - submit a patch adding a __copy__ method to functions,
> - submit a patch for the copy module, or
> - submit a feature request, assign to me, and wait.
Well, actually I am even more ambitious than that: not only I would like
Greg Ewing wrote:
> Unless I'm seriously mistaken, all the Python-equivalent
> loop code that's been presented is only for expositional
> purposes -- in real life, the logic would be embedded in
> the ceval code that implements the for-loop control
> bytecodes, so there would be little or no differ
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>On sre character classes: I don't think that these provide
>>a good approach to XML lexical classes - custom functions
>>or methods or maybe even a codec mapping the characters
>>to their XML lexical class are much more efficient in
>>practice.
>
Guido van Rossum wrote:
> Apologies if this has been discovered and rejected already; I've had
> to skip most of the discussions but this though won't leave my head...
>
> So PEP 310 proposes this:
>
> with VAR = EXPR:
> BLOCK
>
> translated to
>
> VAR = EXPR\
>
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I think we should remove the defaulting to whatever
>>TCL uses and instead warn the user about a possible
>>problem in case TCL is found and uses a Unicode
>>width which is incompatible with Python's choice.
>
> -1.
Martin, please reconsider... t
Guido van Rossum <[EMAIL PROTECTED]> writes:
> Apologies if this has been discovered and rejected already; I've had
> to skip most of the discussions but this though won't leave my head...
>
> So PEP 310 proposes this:
>
> with VAR = EXPR:
> BLOCK
>
> translated to
>
>
28 matches
Mail list logo
