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... the choice
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
to be
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
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
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 why it
[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, and
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 1.3
[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 use
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
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 the
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 complexity?
It
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
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, because
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 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 something. In fact, they
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
[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/)
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
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, +--+
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 them an
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
What about
21 matches
Mail list logo
