Re: [Python-Dev] Problems with definition of _POSIX_C_SOURCE

2005-03-17 Thread Martin v. Löwis
Jack Jansen wrote: The comment in pyconfig.h suggests that defining _POSIX_C_SOURCE may enable certain features, but the actual system headers appear to work the other way around: it seems that defining this will disable features that are not strict Posix. Does anyone know what the real

Re: [Python-Dev] Rationale for sum()'s design?

2005-03-17 Thread Nick Coghlan
Guido van Rossum wrote: I guess that leaves Alex's question of whether or not supplying a string of some description as the initial value can be legitimately translated to: if isinstance(initial, basestring): return initial + type(initial)().join(seq) If you're trying to get people in the

Re: [Python-Dev] itertools.walk()

2005-03-17 Thread Nick Coghlan
Bob Ippolito wrote: I'm not sure why it's useful to explode the stack with all that recursion? Mine didn't do that. The control flow is nearly identical, but it looks more fragile (and you would get some really evil stack trace if iter_factory(foo) happened to raise something other than

[Python-Dev] Python 2.4 won the Jolt productivity award last night

2005-03-17 Thread Guido van Rossum
Python 2.4 won the Jolt productivity award last night. That's the runner-up award; in our category, languages and development tools, the Jolt (the category winner) went to Eclipse 3.0; the other runners-up were IntelliJ and RealBasic (no comment :-). Like usually, open source projects got several

Re: [Python-Dev] Python 2.4 won the Jolt productivity award last night

2005-03-17 Thread Gareth McCaughan
On Thursday 2005-03-17 15:42, Guido van Rossum wrote: Python 2.4 won the Jolt productivity award last night. That's the runner-up award; in our category, languages and development tools, the Jolt (the category winner) went to Eclipse 3.0; the other runners-up were IntelliJ and RealBasic (no

Re: [Python-Dev] properties with decorators (was: code blocks using 'for' loops and generators)

2005-03-17 Thread Jp Calderone
On Thu, 17 Mar 2005 09:01:27 -0800, Josiah Carlson [EMAIL PROTECTED] wrote: Nick Coghlan [EMAIL PROTECTED] wrote: Josiah Carlson wrote: [snip] I think properties are the most used case where this kind of thing would be nice. Though the only thing that I've ever had a gripe

Re: [Python-Dev] properties with decorators (was: code blocks using

2005-03-17 Thread Josiah Carlson
Jp Calderone [EMAIL PROTECTED] wrote: On Thu, 17 Mar 2005 09:01:27 -0800, Josiah Carlson [EMAIL PROTECTED] wrote: Nick Coghlan [EMAIL PROTECTED] wrote: Josiah Carlson wrote: [snip] I think properties are the most used case where this kind of thing would be

[Python-Dev] thread semantics for file objects

2005-03-17 Thread Jeremy Hylton
Are the thread semantics for file objecst documented anywhere? I don't see anything in the library manual, which is where I expected to find it. It looks like read and write are atomic by virtue of fread and fwrite being atomic. I'm less sure what guarantees, if any, the other methods attempt

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Aahz
On Thu, Mar 17, 2005, Jeremy Hylton wrote: Are the thread semantics for file objecst documented anywhere? I don't see anything in the library manual, which is where I expected to find it. It looks like read and write are atomic by virtue of fread and fwrite being atomic. Uncle Timmy will

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Jeremy Hylton
On Thu, 17 Mar 2005 16:25:44 -0500, Aahz [EMAIL PROTECTED] wrote: On Thu, Mar 17, 2005, Jeremy Hylton wrote: Are the thread semantics for file objecst documented anywhere? I don't see anything in the library manual, which is where I expected to find it. It looks like read and write are

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Jeremy Hylton
On Thu, 17 Mar 2005 23:04:16 +0100, Martin v. Löwis [EMAIL PROTECTED] wrote: Jeremy Hylton wrote: Are the thread semantics for file objecst documented anywhere? I don't see anything in the library manual, which is where I expected to find it. It looks like read and write are atomic by virtue

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Jeremy Hylton
On Thu, 17 Mar 2005 17:13:05 -0500, Tim Peters [EMAIL PROTECTED] wrote: [Jeremy Hylton] Are the thread semantics for file objecst documented anywhere? No. At base level, they're inherited from the C stdio implementation. Since the C standard doesn't even mention threads, that's all

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Aahz
On Thu, Mar 17, 2005, Tim Peters wrote: I think Aahz was on target here: NEVER, NEVER access the same file object from multiple threads, unless you're using a lock. And here he went overboard: And even using a lock is stupid. ZODB's FileStorage is bristling with locks

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Martin v. Löwis
Jeremy Hylton wrote: Are the thread semantics for file objecst documented anywhere? Literally, the answer to your question is no. I'm surprised that it does not, for example, guarantee that reads and writes are atomic, since CPython relies on fread and fwrite which are atomic. Where is the

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Tim Peters
[Jeremy Hylton] ... Universal newline reads and get_line() both lock the stream if the platform supports it. So I expect that they are atomic on those platforms. Well, certainly not get_line(). That locks and unlocks the stream _inside_ an enclosing for-loop. Looks quite possible for

Re: [Python-Dev] thread semantics for file objects

2005-03-17 Thread Jeremy Hylton
On Thu, 17 Mar 2005 23:57:52 +0100, Martin v. Löwis [EMAIL PROTECTED] wrote: Remember, you were asking what behaviour is *documented*, not what behaviour is guaranteed by the implementation (in a specific version of the implementation). Martin, I think you're trying to find more finesse in my

[Python-Dev] RELEASED Python 2.4.1, release candidate 2

2005-03-17 Thread Anthony Baxter
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (release candidate 2). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs