On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and
instead print it out or bail out.
Thanks - commenting out the ImportErrors block, I get:
ImportError: No module named encodings
OK got through this - PYTHONPATH in makefile was borked for O
On 08/01/12 19:07, Paul Smedley wrote:
On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and
instead print it out or bail out.
Thanks - commenting out the ImportErrors block, I get:
ImportError: No module named encodings
OK got through this -
On 08/01/12 19:12, Paul Smedley wrote:
On 08/01/12 19:07, Paul Smedley wrote:
On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and
instead print it out or bail out.
Thanks - commenting out the ImportErrors block, I get:
ImportError: No module
> The yes/no answer is "No, we can't drop it".
Thanks, that's a clear answer :-)
> I'm not convinced of the benefits of removing the pure Python RLock
> implementation
Indeed.
As noted, this issue with signal handlers is more general, so this
wouldn't solve the problem at hand. I just wanted to
Phil Vandry TZoNE.ORG> writes:
> proc.stdin, proc.stdout, and proc.stderr aren't meant to be a reference
> to the file that got connected to the subprocess' stdin/stdout/stderr.
> They are meant to be a reference to the OTHER END of the pipe that got
> connected.
Of course, and I've been usi
In http://mail.python.org/pipermail/python-dev/2012-January/115368.html
Stefan Behnel wrote:
> Admittedly, this may require some adaptation for the PEP393 unicode memory
> layout in order to produce identical hashes for all three representations
> if they represent the same content.
They SHOULD N
On Sun, Jan 8, 2012 at 16:33, Jim Jewett wrote:
> In http://mail.python.org/pipermail/python-dev/2012-January/115368.html
> Stefan Behnel wrote:
Can you please configure your mail client to not create new threads
like this? As if this topic wasn't already hard enough to follow, it
now exists acro
On Mon, Jan 9, 2012 at 5:31 AM, charles-francois.natali
wrote:
> Backed out changeset 36f2e236c601: For some reason, rewinddir() doesn't work
> as
> it should on OpenIndiana.
Can rewinddir() end up touching the filesystem to retrieve data? I
noticed that your previous change (the one this check
2012/1/8 Nick Coghlan :
> On Mon, Jan 9, 2012 at 5:31 AM, charles-francois.natali
> wrote:
>> Backed out changeset 36f2e236c601: For some reason, rewinddir() doesn't
>> work as
>> it should on OpenIndiana.
>
> Can rewinddir() end up touching the filesystem to retrieve data? I
> noticed that your
Hello,
I tried to compare the py3k baseline with my randomhash branch but the
benchmark suite is failing.
I've follewed the instruction
# hg clone http://hg.python.org/benchmarks/ py2benchmarks
# mkdir py3benchmarks;
# cd py3benchmarks
# ../py2benchmarks/make_perf3.sh ../py2benchmarks
#
On Mon, 09 Jan 2012 02:01:46 +0100
Christian Heimes wrote:
>
> I tried to compare the py3k baseline with my randomhash branch but the
> benchmark suite is failing.
>
> I've follewed the instruction
For the record, you don't really need this. Just run the "2n3"
benchmark set (it works under both
On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou wrote:
> Depending on the extent of removed/disabled functionality, it might not
> be very interesting to have a Metro port at all.
Win 8 is practically a new OS target - the nt module may need to be
replaced with a metro module to handle it well.
A
12 matches
Mail list logo
