Re: [Python-3000] self-contained exceptions

Phillip J. Eby wrote: > At 12:37 AM 1/12/2007 +1000, Nick Coghlan wrote: >> ...a utility which is also known as contextlib.nested(). >> >> For some strange reason, I suspect you're familiar with that >> particular context manager ;) > > Not that I recall, no, otherwise I'd have used the name. I

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

On 1/11/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > > I've just posted my first pass of the full "lazy strings" patch, with > both "lazy concatenation" and "lazy slices". It's available on > Sourceforge here: > > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1629305&group_id=547

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On 1/11/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > > It applies cleanly (with "patch -p1") against the current revision of > > the Py3k branch, #53392. The resulting tree builds as cleanly as an > > unpatched Py3k, on both Win32 and Linux, and

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

Guido van Rossum wrote: As discussed on that page, the current version of the patch could cause crashes in low-memory conditions. I welcome suggestions on how best to resolve this problem. Apart from that fly in the ointment I'm pretty happy with how it all turned out. What kind of crashes? Th

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

[Larry Hastings] > As discussed on that page, the current version of the patch could cause > crashes in low-memory conditions. I welcome suggestions on how best to > resolve this problem. Apart from that fly in the ointment I'm pretty > happy with how it all turned out. [Guido] > What kind o

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

I don't understand what you mean by #3 and #4; change *which* length? The phrasing of #3 using "hopefully-big-enough" and "odds" immediately makes me think "buffer overflow attack" which is a non-starter. Change the length of the string. Example: our lazy string should be 4032 bytes long, but

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

[Guido] > > I don't understand what you mean by #3 and #4; change *which* length? > > The phrasing of #3 using "hopefully-big-enough" and "odds" immediately > > makes me think "buffer overflow attack" which is a non-starter. On 1/12/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > Change the length

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

Guido van Rossum wrote: Changing the API is the only reasonable solution amongst all the options I've seen. I defer to you. Perhaps another approach will surface; in the meantime I'll start on the API change. You suggested changing the name as a reminder of the semantics change. Are you in

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

On 1/12/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > Changing the API is the only reasonable solution amongst all the options > I've seen. I defer to you. Perhaps another approach will surface; in the > meantime I'll start on the API change. > > You suggested changin

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

Guido van Rossum wrote: I like having a function (not macro) that returns pointer and length through output variables. I proposed a macro because I planned some cheap inlining. Casts and parentheses omitted for *cough* clarity: #define PyUnicode_VALUE(self, p, len) ((self->str != NULL) ? (p

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

On 1/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > [Guido] > > > I don't understand what you mean by #3 and #4; change *which* length? > > > The phrasing of #3 using "hopefully-big-enough" and "odds" immediately > > > makes me think "buffer overflow attack" which is a non-starter. I think 3

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

Jim Jewett wrote: > On 1/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> But IIUC the string may already have been seen by other code, right? >> This violates immutability, and that's not acceptable. > No. > > IIRC, the string was rendered as soon as any code viewed it. Since it > isn't ren

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

Guido van Rossum wrote: Finally (unrelated to the memory problem) I'd like to see some benchmarks to prove that this is really worth it. Here's a first cut at some benchmarks. I gently hacked the pybench in Tools so it'd run, and compared the full "lazy strings" patch to an unpatched tree. In

Re: [Python-3000] Lazy strings (was Re: Py3k release schedule worries)

Larry Hastings <[EMAIL PROTECTED]> wrote: > Of the five I've proposed so far, Guido's right, only changing the API > will preserve the speedup *and* result in correct behavior. But I > maintain some dim hope that a sixth exists, waiting only to be suggested > by some shining intellect. There

[Python-3000] Possible alternative lambda syntax?

I've seen and the various discussions about this, so I hope I'm not beating an utterly dead horse here, so if I am, please ignore this... but I've been thinking about this issue and I had a couple of ideas that I wanted