On Tue, 2007-08-21 at 09:14 -0700, Neal Norwitz wrote:
> The patch is insufficient to prevent all types of crashes that occur
> when accessing a file from 2 threads (closing in one and doing
> whatever in another).
You are right. I wouldn't go so far to say the file object
thread-unsafe, but it c
On Wed, 2007-08-22 at 10:35 +0200, Hrvoje Nikšić wrote:
> I think we need a reliable mechanism to prevent file_close messing with
> f_fp while other operations are being performed. Since each FILE has an
> internal lock associated with it, flockfile could be used to lock out
> the sections that ac
Greg Ewing wrote:
> Paul Moore wrote:
>> What the sentence you quote
>> is trying to say is that if there's a need to compile source, the
>> get_code method must do this on behalf of the caller - it can't return
>> None and expect the caller to try get_source and compile it manually.
>
> Why not s
Georg Brandl wrote:
> Okay, I uploaded a new version without JavaScript and with hidden permalink
> markers.
Very nice. I've compared this version and the 2.4 CHM a little and
while mostly similar, there are several small improvements I appreciate.
One other minor issue, when viewing the "rando
> getpeercert() -- analogue to "getpeeraddr", but returns cert details
This would return three kinds of values:
No certificate received --> None
Certificate received but not validated --> {}
Certificate received and validated --> { full details }
Bill
__
For those of you following along at home, there's now a patch at
http://bill.janssen.org/python/ssl-update-diff which applies against
the current trunk. Working code, though I still need to tweak some
import statements for backwards compatibility. I've started updating
the test suite, see Lib/tes
The Syllable folks apparently still want to support Python, so I'm going to
keep that support in there, switching "atheos" for "syllable" where it
occurs. I have a patch against 2.5.1 from the Syllable folks. I'll see if
I can make it apply to the trunk and py3k branches in a semi-clean fashion.
For a long time I was surprised why if I have a script testme.py:
import subprocess
subprocess.call("echo Something", shell=True)
and I try to execute it like this:
python testme.py >testme.txt
I get the output:
The handle is invalid.
Strange failures randomly happened with di
> Now I finally found that my problem are these two lines in
> subprocess.py:
>
> if stdin is None and stdout is None and stderr is None:
> return (None, None, None, None, None, None)
>
> These lines add an interesting quirk: if I explicitly specify any
> singl
When I was fixing tests failing in the py3k branch, I found the number
duplicate failures annoying. Often, a single bug, in an important
method or function, caused a large number of testcase to fail. So, I
thought of a simple mechanism for avoiding such cascading failures.
My solution is to add a
On 8/22/07, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-08-21 at 09:14 -0700, Neal Norwitz wrote:
> > The patch is insufficient to prevent all types of crashes that occur
> > when accessing a file from 2 threads (closing in one and doing
> > whatever in another).
>
> You are right. I w
On 8/23/07, Mark Hammond <[EMAIL PROTECTED]> wrote:
> > Further investigations showed that it seems to be some strange OS
> > quirk/bug,
> I'm not quite with you here - what strange OS bug do you think you have
> found? I expect that such a bug would be well documented somewhere, even if
> not dir
> C:\>1.py
> hStdOut: 0007
> Something
>
> C:\>1.py>1.txt
> hStdOut: 0004
>
> (1.txt file is now completely empty, i.e. hStdOut is invalid)
Hmm, now I see that maybe that's where I was wrong. When I used
`python 1.py>1.txt' it suddenly started working as expected. :
> > C:\>1.py
> > hStdOut: 0007
> > Something
> >
> > C:\>1.py>1.txt
> > hStdOut: 0004
> >
> > (1.txt file is now completely empty, i.e. hStdOut is invalid)
>
> Hmm, now I see that maybe that's where I was wrong. When I used
> `python 1.py>1.txt' it suddenly started
14 matches
Mail list logo
