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
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
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
#
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
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
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
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
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
> 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
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
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 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
12 matches
Mail list logo
