If not, I'll remove the traces from the docs, where they only serve to confuse
where MacOS X actually belongs under Unix, not Mac.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
One of the things I like about Python is that
* it doesn't actually need an installation. *
It is sufficient to set up PATH (and, if you like, PYTHONPATH)
accordingly to start python. However, you need the DLLs somewhere
in the Python directory, too.
That way it is possible to install Python
Three weeks ago, Antoine Pitrou posted the pybench results
for 2.6 trunk:
http://mail.python.org/pipermail/python-dev/2008-August/081951.html
The big discovery in those results were TryExcept being 48% slower,
but there was a patch in the bug tracker to improve things. I've
re-run the tests to
A.M. Kuchling amk at amk.ca writes:
Bad news: the big slowdowns are:
[snip]
I don't get the same results, but there can be significant variations between
two pybench runs. Did use the same compiler and the same flags for both Python
versions?
___
On Sat, 13 Sep 2008 08:03:50 -0400, A.M. Kuchling [EMAIL PROTECTED] wrote:
Three weeks ago, Antoine Pitrou posted the pybench results
for 2.6 trunk:
http://mail.python.org/pipermail/python-dev/2008-August/081951.html
The big discovery in those results were TryExcept being 48% slower,
but there
On Sat, Sep 13, 2008 at 4:49 AM, Georg Brandl [EMAIL PROTECTED] wrote:
If not, I'll remove the traces from the docs, where they only serve to confuse
where MacOS X actually belongs under Unix, not Mac.
Yes, according to PEP 11, support was removed in 2.4. I suppose this
also means we could
A.M. Kuchling wrote:
Antoine, your Recursion results were actually about the same (+2.2%)
from 2.5 to 2.6, so this big slowdown is novel. I wonder if these
tests are simply slower on MacOS for some reason (compiler, CPU cache
size, etc.). Does anyone see similar results? Any idea what might
The change to universal binaries, perhaps?
That shouldn't really matter - the machine code should still be the
same, and it should all get loaded at program startup. IOW, startup
and imports may get slower, but otherwise, it should have no impact.
Regards,
Martin
Nick Coghlan ncoghlan at gmail.com writes:
That said, I'm seeing big enough swings in the percentages between runs
that I'd like to get some tips on how to smooth out the variations -
e.g. will increasing the warp factor increasing the amount of time each
individual run takes?
Increasing
Hi,
Benjamin Peterson musiccomposition at gmail.com writes:
On Sat, Sep 13, 2008 at 4:49 AM, Georg Brandl g.brandl at gmx.net wrote:
If not, I'll remove the traces from the docs, where they only serve to
confuse where MacOS X actually belongs under Unix, not Mac.
Yes, according to PEP
Hi everybody,
In Python 2.x when iterating over a weak key dictionary for example, the common
idom for doing that was calling dictionary.keys() to ensure that a list of all
objects is returned it was safe to iterate over as a weak reference could stop
existing during dict iteration which of
On Sat, Sep 13, 2008 at 1:20 PM, Armin Ronacher
[EMAIL PROTECTED] wrote:
Hi everybody,
In Python 2.x when iterating over a weak key dictionary for example, the
common
idom for doing that was calling dictionary.keys() to ensure that a list of all
objects is returned it was safe to iterate
On Sep 13, 2008, at 1:03 PM, Antoine Pitrou wrote:
Nick Coghlan ncoghlan at gmail.com writes:
That said, I'm seeing big enough swings in the percentages between
runs
that I'd like to get some tips on how to smooth out the variations -
e.g. will increasing the warp factor increasing the
On Sat, Sep 13, 2008 at 6:05 PM, Leonardo Santagada [EMAIL PROTECTED] wrote:
I would sugest compiling 2.5 and 2.6 from source, run the benchmark x times
and take the smallest time of each test (so os and cpu scalling don't
influence so much the benchmark) and then comparing the results.
I
Josiah Carlson wrote:
On Sat, Sep 13, 2008 at 1:20 PM, Armin Ronacher wrote:
Iterating over weak key dictionaries might not be the most common task but I
know some situations where this is necessary. Unfortunately I can't see a
way to achieve that in Python 3.
i = list(d.keys())
Surely
On Sat, Sep 13, 2008 at 5:21 PM, Scott David Daniels
[EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
On Sat, Sep 13, 2008 at 1:20 PM, Armin Ronacher wrote:
Iterating over weak key dictionaries might not be the most common task
but I
know some situations where this is necessary.
or in FreeBSD?
2.6rc1 and 3.0b3 both fail test_array on FreeBSD7 amd64
test_array passes in 2.5.2 on the same machine but fails test_list the
same as test_array...
*** Signal 9
Not sure if I should file this as a bug or not. I didn't see anything
on bugs.pyhton.org...
~ro
On Sat, Sep 13, 2008 at 8:24 PM, Reed O'Brien [EMAIL PROTECTED] wrote:
or in FreeBSD?
2.6rc1 and 3.0b3 both fail test_array on FreeBSD7 amd64
test_array passes in 2.5.2 on the same machine but fails test_list the same
as test_array...
*** Signal 9
Not sure if I should file this as a bug
On Sat, Sep 13, 2008 at 2:20 PM, Armin Ronacher
[EMAIL PROTECTED] wrote:
Hi everybody,
In Python 2.x when iterating over a weak key dictionary for example, the
common
idom for doing that was calling dictionary.keys() to ensure that a list of all
objects is returned it was safe to iterate
Dear Prashanth,
Many thanks, it worked like it should.
Best regards,
Vinay
On Sat, 13 Sep 2008 13:08:11 +0530, Prashanth [EMAIL PROTECTED]
wrote:
AddColumn(IIf(Result 0 ,AA, AB),Column4);
Add the above syntax and you should get the required.
Cheers
Prashanth
- Original Message
20 matches
Mail list logo
