Brett Cannon wrote:
I fixed the crasher for ``int(buffer(array.array('c')))`` by making
buffer objects operate properly. Problem is that by doing so I broke
the ctypes tests with a bunch of similar errors::
You have not yet committed this fix, right?
Thomas Heller wrote:
I think that hexlify should be able to use any buffer object that has
a readable memory block, not only those with charbuffers.
The docs say that the binascii methods are used to convert between binary
and various ASCII-encoded binary representations.
So why the heck
M.-A. Lemburg wrote:
Still, here's the timeit.py measurement of the PythonFunctionCall
test (note that I've scaled down the test in terms of number
of rounds for timeit.py):
Python 2.4:
10 loops, best of 3: 21.9 msec per loop
10 loops, best of 3: 21.8 msec per loop
10 loops, best of 3:
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Still, here's the timeit.py measurement of the PythonFunctionCall
test (note that I've scaled down the test in terms of number
of rounds for timeit.py):
Python 2.5 as of last night:
10 loops, best of 3: 21.9 msec per loop
10 loops, best of 3: 21.8
M.-A. Lemburg wrote:
Still, here's the timeit.py measurement of the PythonFunctionCall
test (note that I've scaled down the test in terms of number
of rounds for timeit.py):
Python 2.4:
10 loops, best of 3: 21.9 msec per loop
10 loops, best of 3: 21.8 msec per loop
10 loops, best of 3:
M.-A. Lemburg wrote:
sigh I put the headings for the timeit.py output on the
wrong blocks. Thanks for pointing this out.
so how do you explain the Try/Except results, where timeit and pybench
seems to agree?
/F
___
Python-Dev mailing list
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
sigh I put the headings for the timeit.py output on the
wrong blocks. Thanks for pointing this out.
so how do you explain the Try/Except results, where timeit and pybench
seems to agree?
The pybench results match those of timeit.py on my test
M.-A. Lemburg wrote:
The pybench results match those of timeit.py on my test machine
in both cases. I just mixed up the headers when I wrote the email.
on a line by line basis ?
Testnamesminimum run-timeaverage run-time
this
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
The pybench results match those of timeit.py on my test machine
in both cases. I just mixed up the headers when I wrote the email.
on a line by line basis ?
No idea what you mean ? I posted the corrected version after Nick
told me about the
On Thu, Jun 08, 2006 at 12:18:23AM -0400, Terry Reedy wrote:
I am willing to do perhaps half the work needed to produce such in time for
the 2.5 release. In particular, I am willing to write a plain text file
listing symbols (in ascii sort order) and section numbers, in an agreed-on
M.-A. Lemburg wrote:
The pybench results match those of timeit.py on my test machine
in both cases.
but they don't match the timeit results on similar machines, nor do they
reflect what was done at the sprint.
Tools/pybench ~/projects/Python/Installation/bin/python Calls.py
10 loops,
M.-A. Lemburg wrote:
The results were produced by pybench 2.0 and use time.time
on Linux, plus a different calibration strategy. As a result
these timings are a lot more repeatable than with pybench 1.3
and I've confirmed the timings using several runs to make sure.
can you check in 2.0 ?
On Thu, 8 Jun 2006, A.M. Kuchling wrote:
On Thu, Jun 08, 2006 at 12:18:23AM -0400, Terry Reedy wrote:
I am willing to do perhaps half the work needed to produce such in time for
the 2.5 release. In particular, I am willing to write a plain text file
listing symbols (in ascii sort order) and
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
The pybench results match those of timeit.py on my test machine
in both cases.
but they don't match the timeit results on similar machines, nor do they
reflect what was done at the sprint.
Huh ? They do show the speedups you achieved at the
M.-A. Lemburg wrote:
Huh ? They do show the speedups you achieved at the sprint.
the results you just posted appear to show a 20% slowdown for function
calls, and a 10% speedup for exceptions.
both things were optimized at the sprint, and the improvements were
confirmed on several machines.
On 6/8/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
All this on AMD64, Linux2.6, gcc3.3.FWIW, my AMD64, linux 2.6, gcc 4.0 machine reports 29.0-29.5 usec for 2.5, 30.0-31.0 for 2.4 and 30.5-31.5 for 2.3, using the code you attached. In other words, 2.5
is definately not slower here. At least, not
Thomas Wouters wrote:
On 6/8/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
All this on AMD64, Linux2.6, gcc3.3.
FWIW, my AMD64, linux 2.6, gcc 4.0 machine reports 29.0-29.5 usec for 2.5,
30.0-31.0 for 2.4 and 30.5-31.5 for 2.3, using the code you attached. In
other words, 2.5 is definately
On 6/8/06, Thomas Heller [EMAIL PROTECTED] wrote:
Brett Cannon wrote: I fixed the crasher for ``int(buffer(array.array('c')))`` by making buffer objects operate properly.Problem is that by doing so I broke the ctypes tests with a bunch of similar errors::
You have not yet committed this fix,
Phillip,
1. It's not really clear from the abstract 'what' this library
provides. You might want
to consider moving the text from 1.1 up to the same level as the abstract.
2. In section 1.1 you might want to consider dropping the sentence:
Only authors
of web servers and programming
On 6/8/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Perhaps it's a new feature in gcc 4.0 that makes the slow-down I seeturn into a speedup :-)It seems so. I tested with gcc 2.95, 3.3 and 4.0 on FreeBSD 4.10 (only machine I had available with those gcc versions) and both
2.95 and 4.0 show a 10-20%
Thomas Wouters wrote:
On 6/8/06, *M.-A. Lemburg* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Perhaps it's a new feature in gcc 4.0 that makes the slow-down I see
turn into a speedup :-)
It seems so. I tested with gcc 2.95, 3.3 and 4.0 on FreeBSD 4.10 (only
machine I
Thomas Wouters wrote:
On 6/8/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Perhaps it's a new feature in gcc 4.0 that makes the slow-down I see
turn into a speedup :-)
It seems so. I tested with gcc 2.95, 3.3 and 4.0 on FreeBSD 4.10 (only
machine I had available with those gcc versions)
On 6/8/06, Georg Brandl [EMAIL PROTECTED] wrote:
Does 4.0 show a general slowdown on your test machines? I saw a dropof average Pystones from 44000 to 4 and from 42000 to 39000 onmy boxes switching from GCC 3.4.6 to 4.1.1.Yep, looks like it does. Don't have time to run more extensive tests,
On 5/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Then options 2 and 3 are both fine.
Not compiling at all is *not*, so if nobody has time to implement 2 or
3, we'll have to do 4.
--Guido
Is this thread still alive?
I've posted patch #1503046 to sourceforge which implements option #2
Chris AtLee wrote:
On 5/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Then options 2 and 3 are both fine.
Not compiling at all is *not*, so if nobody has time to implement 2 or
3, we'll have to do 4.
--Guido
Is this thread still alive?
At least I still have this on my todo list.
On Mon, 5 Jun 2006, Nick Coghlan wrote:
[...]
I started to write a reply to this with some comments on the API (including
the internal subclassing API), but ended up with so many different
suggestions it was easier to just post a variant of the module. I called it
urischemes and posted it
Maybe this belongs in the dev faq. I didn't see anything there or in the
Subversion book.
I have three Python branches, trunk, release23-maint and release24-maint.
In the (for example) release24-maint, what svn up command would I use to get
to the 2.4.2 version? In cvs I'd use something like
I'm working in Windows 2K SP4. I have a directory with non-ascii names
(i.e.: camión.txt).
I'm trying to tar.bzip it:
nomdir = sys.argv[1]
tar = tarfile.open(prueba.tar.bz2, w:bz2)
tar.add(nomdir)
tar.close()
This works ok, even considering that the ó in the filename is not
On Thu, Jun 08, 2006 at 01:52:09PM -0500, [EMAIL PROTECTED] wrote:
Maybe this belongs in the dev faq. I didn't see anything there or in the
Subversion book.
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.checkout.html
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.update.html
I
[EMAIL PROTECTED]
Maybe this belongs in the dev faq. I didn't see anything there or in the
Subversion book.
I have three Python branches, trunk, release23-maint and release24-maint.
In the (for example) release24-maint, what svn up command would I use to get
to the 2.4.2 version? In cvs
Oleg,
Thanks for the help. With the tags url I was able to identify the revision
I needed to update to.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I have three Python branches, trunk, release23-maint and
release24-maint. In the (for example) release24-maint, what svn up
command would I use to get to the 2.4.2 version?
Tim First question:
Timcd to the root of your release24-maint checkout, then
Timsvn
On Thu, Jun 08, 2006 at 02:55:29PM -0500, [EMAIL PROTECTED] wrote:
Timsvn switch svn+ssh://[EMAIL PROTECTED]/python/tags/r242
How is that different than noting that r242 corresponds to revision 39619
and executing:
svn up -r 39619
svn up updates the working directory
On Fri, Jun 09, 2006 at 12:03:54AM +0400, Oleg Broytmann wrote:
svn switch updates *and* switch the base URL - commits will go to the
tag/branch you are switching to.
Another point of view: svn switch is kind of optimized svn checkout.
svn co starts afresh and needs to transfer the entire
A.M. Kuchling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thu, Jun 08, 2006 at 12:18:23AM -0400, Terry Reedy wrote:
[I just realized that some links need to be within-page rather than to
the
top of the page and that I can cut and paste additional info if I find
the
Facundo Batista wrote:
This is because tarinfo.tobuf() creates a unicode object (because it
has the filename on it), and file.write() must have a standard string.
This is a known problem? Shall I post a bug? Couldn't find any
regarding this, and google didn't help here.
You could file a bug
FYI, here's the minimal set of failing tests:
$ python_d ../Lib/test/regrtest.py test_file test_optparse
test_file
test_optparse
test test_optparse failed -- Traceback (most recent call last):
File C:\Code\python\lib\test\test_optparse.py, line 1042, in
test_filetype_noexist
On 6/8/06, Tim Peters [EMAIL PROTECTED]
wrote:
FYI, here's the minimal set of failing tests:$ python_d ../Lib/test/regrtest.py test_file test_optparsetest_filetest_optparsetest test_optparse failed -- Traceback (most recent call last):File C:\Code\python\lib\test\test_optparse.py, line 1042, in
[Tim]
FYI, here's the minimal set of failing tests:
$ python_d ../Lib/test/regrtest.py test_file test_optparse
test_file
test_optparse
test test_optparse failed -- Traceback (most recent call last):
File C:\Code\python\lib\test\test_optparse.py, line 1042, in
test_filetype_noexist
On 6/8/06, Tim Peters [EMAIL PROTECTED] wrote:
[Tim] FYI, here's the minimal set of failing tests: $ python_d ../Lib/test/regrtest.py test_file test_optparse test_file test_optparse test test_optparse failed -- Traceback (most recent call last):
File C:\Code\python\lib\test\test_optparse.py, line
...
[Tim]
What revision was your laptop at before the update? It could help a
lot to know the earliest revision at which this fails.
[Brett]
No clue. I had not updated my local version in quite some time since most
of my dev as of late has been at work.
A good clue is to look at the
On 6/8/06, Tim Peters [EMAIL PROTECTED] wrote:
...[Tim] What revision was your laptop at before the update?It could help a lot to know the earliest revision at which this fails.[Brett] No clue.I had not updated my local version in quite some time since most
of my dev as of late has been at
Well, this sure sucks. This is the earliest revision at which the tests fail:
r46752 | georg.brandl | 2006-06-08 10:50:53 -0400 (Thu, 08 Jun 2006) | 3 lines
Changed paths:
M /python/trunk/Lib/test/test_file.py
Convert test_file to unittest.
If _that's_ not a reason for using doctest, I
On 6/8/06, Tim Peters [EMAIL PROTECTED] wrote:
Well, this sure sucks.This is the earliest revision at which the tests fail:r46752 | georg.brandl | 2006-06-08 10:50:53 -0400 (Thu, 08 Jun 2006) | 3 linesChanged paths: M /python/trunk/Lib/test/test_file.py
Convert test_file to unittest.If _that's_
[Tim]
Well, this sure sucks. This is the earliest revision at which the
tests fail:
r46752 | georg.brandl | 2006-06-08 10:50:53 -0400 (Thu, 08 Jun
2006) | 3 lines
Changed paths:
M /python/trunk/Lib/test/test_file.py
Convert test_file to unittest.
If _that's_ not a reason for using
John J Lee wrote:
http://python.org/sf/1500504
[...]
At first glance, looks good. I hope to review it properly later.
One point: I don't think there should be any mention of URL in the
module -- we should use URI everywhere (see my comments on Paul's
original version for a bit more
46 matches
Mail list logo
