[Python-Dev] inspect.py very slow under 2.5

Hi all, I know that the 2.5 release is extremely close, so this will probably be 2.5.1 material. I discussed it briefly with Guido at scipy'06, and he asked for some profile-based info, which I've only now had time to gather. I hope this will be of some use, as I think the problem is rather seri

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

At 02:08 AM 9/6/2006 +0100, David Hopwood wrote: >Barry Warsaw wrote: > > The bias with these terms is clearly the English left-to-right > > order. Actually, that brings up an interesting question: what would > > happen if you called rpartition on a unicode string representing > > Hebrew, Arabic,

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Barry Warsaw wrote: > The bias with these terms is clearly the English left-to-right > order. Actually, that brings up an interesting question: what would > happen if you called rpartition on a unicode string representing > Hebrew, Arabic, or other RTL language? Do partition and rpartition

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/5/06, Nick Maclaren <[EMAIL PROTECTED]> wrote: [...] > Even if write is atomic, there are gotchas. What if the interrupted > code is doing something to that file at the time? Are you SURE that > an unexpected operation on it (in the same thread) won't cause the > library function of program

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

See, for me, it's all about the results of the operation, not how the results are (supposedly) used. The way I think about it is that I've got some string and I'm looking for some split point within that string. That split point is clearly the "middle" (but "sep" works too) and every

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote: >On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote: > > > I think I finally figured out where Raymond is coming from. > > > > For Raymond, "head" is where he started processing -- for rpartition, > > this is the .endswith part. > > > > For me, "head" is th

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote: > I think I finally figured out where Raymond is coming from. > > For Raymond, "head" is where he started processing -- for rpartition, > this is the .endswith part. > > For me, "head" is the start of the

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

I think I finally figured out where Raymond is coming from. For Raymond, "head" is where he started processing -- for rpartition, this is the .endswith part. For me, "head" is the start of the data structure -- always the .startswith part. We won't resolve that with anything suggesting a sequent

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2006, at 4:13 PM, Raymond Hettinger wrote: > Tim Peters wrote: > >>upto, sep, rest >> >> in whatever order they apply. >> > In the rpartition case, that would be (rest, sep, upto) which seems a > bit cryptic. > > We need some choice of w

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Tim Peters wrote: >upto, sep, rest > >in whatever order they apply. > In the rpartition case, that would be (rest, sep, upto) which seems a bit cryptic. We need some choice of words that clearly mean: * the chopped-off snippet (guaranteed to not contain the separator) * the separator if f

Re: [Python-Dev] Signals, threads, blocking C functions

Johan Dahlin <[EMAIL PROTECTED]> wrote: > > Are you saying that we should let less commonly used platforms dictate > features and functionality for the popular ones? > I mean, who uses HP/UX, SCO and [insert your favorite flavor] as a modern > desktop system where this particular bug makes a differ

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On 9/5/06, Tim Peters <[EMAIL PROTECTED]> wrote: > upto, sep, rest > > in whatever order they apply. I think of a partition-like function as > starting at some position and matching "up to" the first occurence of > the separator (be that left or right or diagonally, "up to" is > relative to th

Re: [Python-Dev] 2.5 status

On 9/5/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 9/4/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: There are 3 bugs currently listed in PEP 356 as blocking:>> http://python.org/sf/1551432 - __unicode__ breaks on exception>> classes>>> I replied on the bug repor

Re: [Python-Dev] 2.5 status

Brett Cannon wrote: > On 9/4/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: >> >> There are 3 bugs currently listed in PEP 356 as blocking: >> http://python.org/sf/1551432 - __unicode__ breaks on exception >> classes > > > I replied on the bug report, but might as well comment here. > > The

Re: [Python-Dev] 2.5 status

On 9/5/06, Georg Brandl <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:>>> On 9/4/06, *Neal Norwitz* <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote: >> There are 3 bugs currently listed in PEP 356 as blocking:> http://python.org/sf/1551432 - __unicode__ breaks on> exception classe

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

upto, sep, rest in whatever order they apply. I think of a partition-like function as starting at some position and matching "up to" the first occurence of the separator (be that left or right or diagonally, "up to" is relative to the search direction), and leaving "the rest" alone. The docs

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Ron Adam wrote: >I hope this discussion is only about the words used and the >documentation and not about the actual order of what is received. I >would expect both the following should be true, and it is the current >behavior. > > ''.join(s.partition(sep)) -> s > ''.join(s.rpartition(sep)

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Raymond Hettinger wrote: > Another thought is that strings don't really have a left and right. > They have a beginning and end. The left/right or top/bottom distinction > is culture specific. Well, it should have been epartition() and not rpartition() in that case. ;-) Is python ever edite

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2006, at 2:32 PM, Raymond Hettinger wrote: > Another thought is that strings don't really have a left and right. > They have a beginning and end. The left/right or top/bottom > distinction > is culture specific. For the target of the met

Re: [Python-Dev] 2.5 status

Brett Cannon wrote: > > > On 9/4/06, *Neal Norwitz* <[EMAIL PROTECTED] > > wrote: > > There are 3 bugs currently listed in PEP 356 as blocking: > http://python.org/sf/1551432 - __unicode__ breaks on > exception classes > > > I replied on the bug re

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Ron Adam wrote: Correcting myself... > I hope this discussion is only about the words used and the > documentation and not about the actual order of what is received. I > would expect both the following should be true, and it is the current > behavior. > > ''.join(s.partition(sep)) -> s >

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Michael Chermside wrote: > Jim Jewett writes: >> This change [in docs] looks wrong: >> >> PyDoc_STRVAR(rpartition__doc__, >> -"S.rpartition(sep) -> (head, sep, tail)\n\ >> +"S.rpartition(sep) -> (tail, sep, head)\n\ > > Raymond Hettinger replies: >> It is correct. There may be some confusion in t

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Jim Jewett wrote: > > Another possibility is data (for head/tail) and unparsed (for rest). > >S.partition(sep) -> (data, sep, unparsed) >S.rpartition(sep) -> (unparsed, sep, data) This communicates very little about the ordering of the return tuple. Beware of overly general terms like

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On 9/5/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sep 5, 2006, at 2:06 PM, Raymond Hettinger wrote: > > >> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail) > > > > Gads, the cure is worse than the disease. > > > > car and

Re: [Python-Dev] 2.5 status

On 9/4/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: There are 3 bugs currently listed in PEP 356 as blocking:http://python.org/sf/1551432 - __unicode__ breaks on exception classesI replied on the bug report, but might as well comment here. The problem with this bug is that BaseException now

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On Tue, 5 Sep 2006, Fred L. Drake, Jr. wrote: > On Tuesday 05 September 2006 13:24, Michael Chermside wrote: > > How about something like this: > > > > S.partition(sep) -> (head, sep, tail) > > S.rpartition(sep) -> (tail, sep, rest) > > I think I prefer: > >S.partition(sep) -> (head, s

Re: [Python-Dev] Signals, threads, blocking C functions

Johan Dahlin wrote: > Nick Maclaren wrote: >> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote: >>> I'm pretty sure writing to a pipe is async signal safe. It is the >>> oldest trick in the book, everyone uses it. I ... know that it works. >> Ah. Well, I can assure you that it's not the oldes

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2006, at 2:06 PM, Raymond Hettinger wrote: >> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail) > > Gads, the cure is worse than the disease. > > car and cdr are starting to look pretty good ;-) LOL, the lisper in me likes

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On Tuesday 05 September 2006 14:02, Jim Jewett wrote: > Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail) Whichever matches reality, sure. I've lost track of the rpartition() result order. --sigh-- > Another possibility is data (for head/tail) and unparsed (for rest). > >

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

> > Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail) Gads, the cure is worse than the disease. car and cdr are starting to look pretty good ;-) Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailma

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On 9/5/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > S.partition(sep) -> (head, sep, rest) > S.rpartition(sep) -> (tail, sep, rest) > Here, "rest" is always used for "what remains"; head/tail are somewhat more > clear here I think. Then shouldn't rpartition be S.rpartition(sep) ->

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On Tuesday 05 September 2006 13:46, Raymond Hettinger wrote: > Changing to left/sep/right will certainly disambiguate questions about left/right is definately not helpful. It's also ambiguous in the case of .rpartition(), where left and right in the input and result are different. > the order

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2006, at 1:46 PM, Raymond Hettinger wrote: >> ISTM this is just begging for newbie (and maybe not-so-newbie) >> confusion. Why not just document both as returning (left, sep, >> right) which seems the most obvious description of what

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

On Tuesday 05 September 2006 13:24, Michael Chermside wrote: > How about something like this: > > S.partition(sep) -> (head, sep, tail) > S.rpartition(sep) -> (tail, sep, rest) I think I prefer: S.partition(sep) -> (head, sep, rest) S.rpartition(sep) -> (tail, sep, rest) Here

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

> ISTM this is just begging for newbie (and maybe not-so-newbie) > confusion. Why not just document both as returning (left, sep, > right) which seems the most obvious description of what the methods > return? I'm fine with that (though it's a little sad that we think the rather basic co

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2006, at 1:10 PM, Raymond Hettinger wrote: >> This change looks wrong: >> >> PyDoc_STRVAR(rpartition__doc__, >> -"S.rpartition(sep) -> (head, sep, tail)\n\ >> +"S.rpartition(sep) -> (tail, sep, head)\n\ >> >> It looks like the code itself do

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Jim Jewett writes: > This change [in docs] looks wrong: > > PyDoc_STRVAR(rpartition__doc__, > -"S.rpartition(sep) -> (head, sep, tail)\n\ > +"S.rpartition(sep) -> (tail, sep, head)\n\ Raymond Hettinger replies: > It is correct. There may be some confusion in terminology. Head > and tail do not

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

> > This change looks wrong: > > PyDoc_STRVAR(rpartition__doc__, > -"S.rpartition(sep) -> (head, sep, tail)\n\ > +"S.rpartition(sep) -> (tail, sep, head)\n\ > > It looks like the code itself does the right thing, but I wasn't quite > confident of that. > It is correct. There may be some confusion

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

> Jim Jewett wrote: > >Why not just change which of the three strings holds the remainder in > >the not-found case? On 9/5/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > That was the only change submitted. > Are you happy with what was checked-in? This change looks wrong: PyDoc_STRVAR(rpart

Re: [Python-Dev] Signals, threads, blocking C functions

Nick Maclaren wrote: > "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote: >> Anyway, I was speaking hypothetically. I'm pretty sure writing to a >> pipe is async signal safe. It is the oldest trick in the book, >> everyone uses it. I don't have to see a written signed contract to >> know that it work

Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()

Jim Jewett wrote: > >Why not just change which of the three strings holds the remainder in >the not-found case? > > That was the only change submitted. Are you happy with what was checked-in? Raymond ___ Python-Dev mailing list Python-Dev@python.o

[Python-Dev] Fwd: Problem withthe API for str.rpartition()

Reversing the order of the return tuple will break the alignment with split/rsplit. Why not just change which of the three strings holds the remainder in the not-found case? In rc1, "d".rpartition(".") --> ('d', '', '') If that changes to "d".rpartition(".") --> ('', '', 'd') then (1)

Re: [Python-Dev] no remaining issues blocking 2.5 release

> Did you still want this addressed? Anthony and I made some comments > on the bug/patch, but nothing has been updated. I was waiting because I got unassigned from the bug, so I thought the maintainer was stepping up. I'll commit a fix for it today. Thanks for pinging me, -- Gustavo Niemeyer

Re: [Python-Dev] Signals, threads, blocking C functions

"Gustavo Carneiro" <[EMAIL PROTECTED]> wrote: > > Anyway, I was speaking hypothetically. I'm pretty sure writing to a > pipe is async signal safe. It is the oldest trick in the book, > everyone uses it. I don't have to see a written signed contract to > know that it works. Ah. Well, I can assu

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/5/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > On 9/4/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: > > Now, we've had this API for a long time already (at least 2.5 > > years). I'm pretty sure it works well enough on most *nix systems. > > Event if it works 99% of the times, it's way bett

Re: [Python-Dev] Cross-platform math functions?

Nick Maclaren wrote: > The word "better" is emotive and inaccurate. Such calculations are > numerically meaningless, and merely encourage the confusion between > consistency and correctness. There is a strong sense in which giving > random results between -1 and 1 would be better. I did, of cour

Re: [Python-Dev] Signals, threads, blocking C functions

"Adam Olsen" <[EMAIL PROTECTED]> wrote: > On 9/4/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: > > > Now, we've had this API for a long time already (at least 2.5 > > years). I'm pretty sure it works well enough on most *nix systems. > > Event if it works 99% of the times, it's way better tha

[Python-Dev] Cross-platform math functions?

Andreas Raab <[EMAIL PROTECTED]> wrote: > > I'm curious if there is any interest in the Python community to achieve > better cross-platform math behavior. A quick test[1] shows a > non-surprising difference between the platform implementations. > Question: Is there any interest in changing the