> > 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
> 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. :
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
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
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
> 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
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
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 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
> 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
__
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
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
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
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
14 matches
Mail list logo
