Jeremy Hylton wrote:
It sounds like the weakest intended behavior we have is the one Tim
reported: "provided the platform C stdio wasn't thread-braindead,
then if you had N threads all simultaneously reading a file object
containing B bytes, while nobody wrote to that file object, then the
total n
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 squi
>The C implementation has this code:
>
>"""
> if (PyDict_DelItem(so->data, item) == -1) {
> if (!PyErr_ExceptionMatches(PyExc_KeyError))
> return NULL;
> PyErr_Clear();
> }
>"""
>
>Which is more-or-less the same as the sets.Set version,
>>> But the dict.pop method is about 12 times faster. Is this
>>> worth doing?
>>
>> The 2.4 builtin set's discard function looks like it does
>> roughly the same as the 2.3 sets.Set. Have you tried comparing
>> a C version of your version with the 2.4 set to see if there are
>> speedups there,
>> But the dict.pop method is about 12 times faster. Is this worth doing?
>
>The 2.4 builtin set's discard function looks like it does roughly the same
>as the 2.3 sets.Set. Have you tried comparing a C version of your version
>with the 2.4 set to see if there are speedups there, too?
Ah. I had f
> To avoid the exception in the discard method, it could be
> implemented as:
>
> def discard(self, element):
> """Remove an element from a set if it is a member.
>
> If the element is not a member, do nothing.
> """
> try:
> self._data.pop(element
To avoid the exception in the discard method, it could be implemented as:
def discard(self, element):
"""Remove an element from a set if it is a member.
If the element is not a member, do nothing.
"""
try:
self._data.pop(element, None)
excep
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
G'day,
the recent thread about thread semantics for file objects reminded me I
had a draft pep for extending file objects to support non-blocking
mode.
This is handy for handling files in async applications (the non-threaded
way of doing things concurrently).
Its pretty rough, but if I fuss ove
Amazingly on time thanks to the quarter being over. You can't see me jumping
up and down in joy over that fact, but I am while trying not to hit the ceiling
as I do it (for those of you who have never met me, I'm 6'6" tall, so jumping
in a room is not always the smartest thing for me, especiall
[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 diff
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 connec
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 wit
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
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
[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
platform-dependent. POSIX defines thread semantics for file I/O, but
fat lot of go
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 no doubt agree with me: the se
Jeremy Hylton wrote:
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 a
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
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 wi
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 to
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 thi
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 th
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> [snip]
> >>well, I think some people desire a more streamlined way of writing code
> >>like:
> >>
> >>def f(...)
> >>...
> >>def g(...)
> >>...
> >>x = h(...,f,g)
> >>
> >>[property,
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
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 severa
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
TypeE
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 ha
Josiah Carlson wrote:
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
[snip]
well, I think some people desire a more streamlined way of writing code
like:
def f(...)
...
def g(...)
...
x = h(...,f,g)
[property, setting up callbacks etc are cases of this]
I think properties are the most used case where
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 meaning
30 matches
Mail list logo
