date:20060608

Re: [Python-Dev] Is "t#" argument format meant to be char buffer, or just read-only?

2006-06-08 Thread Thomas Heller

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?

> ==
> ERROR: test_endian_double (ctypes.test.test_byteswap.Test)
> --
> Traceback (most recent call last):
>   File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line
> 134, in test_endian_double
> self.failUnlessEqual(bin(struct.pack("d", math.pi)), bin(s))
>   File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 7, in bin
> return hexlify(buffer(s)).upper()
> TypeError: requested buffer type not available
> 
> Turns out the test does the following::
> 
>   binascii.hexlify(buffer(ctypes.c_double(math.pi)))
> 
> This is a problem because binascii.hexlify() uses "t#" as its argument
> format string to PyArg_ParseTuple() and that fails now with a
> TypeError since ctypes.c_double (which subclasses ctypes._SimpleCData
> which defines the buffer interface) does not have a char buffer
> defined.
> 
> Now this used to pass since buffer objects just used the read or write
> buffer in place of the char buffer, regardless if the wrapped object
> had a char buffer function defined.
> 
> But in checking out what "t#" did, I found a slight ambiguity in the
> docs.  The docs say "read-only character buffer" for the short
> description, but "read-only buffer" for the longer description.  Which
> is it?

I am using binascii.hexlify(buffer(obj)) as a simple way to look at the bytes of
the memory block.

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".


> Plus, Thomas, you might want to change _SimpleCData if you want it to
> truly suport char buffers.

I did not implement that because the memory block contains binary data,
not text.

Thomas

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
> 
>> Some more interesting results from comparing Python 2.4 (other) against
>> the current SVN snapshot (this):
> 
> been there, done that, found the results lacking.
> 
> we spent a large part of the first NFS day to investigate all
> reported slowdowns, and found that only one slowdown could be 
> independently confirmed (the exception issue).
> 
> try running some of your subtests under timeit, and see if you
> can repeat the results.

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.

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: 21.8 msec per loop
10 loops, best of 3: 21.9 msec per loop
10 loops, best of 3: 21.9 msec per loop

Python 2.5 as of last night:
100 loops, best of 3: 18 msec per loop
100 loops, best of 3: 18.4 msec per loop
100 loops, best of 3: 18.4 msec per loop
100 loops, best of 3: 18.2 msec per loop

The pybench 2.0 result:

PythonFunctionCalls:   130ms   108ms  +21.3%   132ms   109ms  +20.9%

Looks about right, I'd say.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  24 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is "t#" argument format meant to be char buffer, or just read-only?

2006-06-08 Thread Greg Ewing

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 is hexlify looking for charbuffers and not
byte buffers in the first place?

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Nick Coghlan

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: 21.8 msec per loop
> 10 loops, best of 3: 21.9 msec per loop
> 10 loops, best of 3: 21.9 msec per loop
> 
> Python 2.5 as of last night:
> 100 loops, best of 3: 18 msec per loop
> 100 loops, best of 3: 18.4 msec per loop
> 100 loops, best of 3: 18.4 msec per loop
> 100 loops, best of 3: 18.2 msec per loop
> 
> The pybench 2.0 result:
> 
> PythonFunctionCalls:   130ms   108ms  +21.3%   132ms   109ms  +20.9%
> 
> Looks about right, I'd say.

If the pybench result is still 2.5 first, then the two results are 
contradictory - your timeit results are showing Python 2.5 as being faster 
(assuming the headings are on the right blocks of tests).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

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 msec per loop
>> 10 loops, best of 3: 21.8 msec per loop
>> 10 loops, best of 3: 21.9 msec per loop
>> 10 loops, best of 3: 21.9 msec per loop

Python 2.4:

>> 100 loops, best of 3: 18 msec per loop
>> 100 loops, best of 3: 18.4 msec per loop
>> 100 loops, best of 3: 18.4 msec per loop
>> 100 loops, best of 3: 18.2 msec per loop
>>
>> The pybench 2.0 result:
>>
>> PythonFunctionCalls:   130ms   108ms  +21.3%   132ms   109ms  +20.9%
>>
>> Looks about right, I'd say.
> 
> If the pybench result is still 2.5 first, then the two results are
> contradictory - your timeit results are showing Python 2.5 as being
> faster (assuming the headings are on the right blocks of tests).

 I put the headings for the timeit.py output on the
wrong blocks. Thanks for pointing this out.

Anyway, try for yourself. Just add these lines to pybench/Call.py
at the end and then run Call.py using Python 2.4 vs. 2.5:

### Test to make Fredrik happy...

if __name__ == '__main__':
import timeit
timeit.TestClass = PythonFunctionCalls
timeit.main(['-s', 'test = TestClass(); test.rounds = 1000',
 'test.test()'])

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  24 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Fredrik Lundh

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: 21.8 msec per loop
> 10 loops, best of 3: 21.9 msec per loop
> 10 loops, best of 3: 21.9 msec per loop
> 
> Python 2.5 as of last night:
> 100 loops, best of 3: 18 msec per loop
> 100 loops, best of 3: 18.4 msec per loop
> 100 loops, best of 3: 18.4 msec per loop
> 100 loops, best of 3: 18.2 msec per loop
> 
> The pybench 2.0 result:
> 
> PythonFunctionCalls:   130ms   108ms  +21.3%   132ms   109ms  +20.9%
> 
> Looks about right, I'd say.

except for the sign, I'd say.

pybench reported a slowdown from 108 to 130 ms, which prompted you to write

 > A little disturbing is the slow-down for Python function calls
 > and the built-in method lookup. Did anything change in these parts
 > of the interpreter ?

but timeit is reporting a ~20% speedup (21.8 to 18 ms).  on my machine, 
using the loop body from Calls.PythonFunctionCalls.test as a separate 
global function called by timeit, I get:

 25 usec per loop for Python 2.4.3
 22.5 usec per loop for Python 2.5 trunk

which seems to match your timeit results quite well.  and we *did* speed 
up frame handling on the reykjavik sprint.

another sprint optimization was exception handling, and pybench did 
notice this (137 to 115 ms).  here's what timeit says on my machine:

 15.1 usec per loop for Python 2.4.3
 23.5 usec per loop for Python 2.5 alpha 2
 11.6 usec per loop for Python 2.5 trunk

something's not quite right...



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Fredrik Lundh

M.-A. Lemburg wrote:

>  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?



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
> 
>>  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 machine
in both cases. I just mixed up the headers when I wrote the email.

Here's the console print-out:

Tools/pybench> ~/projects/Python/Installation/bin/python Calls.py
10 loops, best of 3: 21.8 msec per loop
Tools/pybench> ~/projects/Python/Installation/bin/python Exceptions.py
100 loops, best of 3: 15.4 msec per loop

Tools/pybench> ~/projects/Python/Installation/bin/python
Python 2.5a2 (trunk, Jun  8 2006, 01:51:06)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2

Tools/pybench> python Calls.py
100 loops, best of 3: 18.2 msec per loop
Tools/pybench> python Exceptions.py
100 loops, best of 3: 17 msec per loop

Tools/pybench> python
Python 2.4.2 (#1, Oct  1 2005, 15:24:35)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2

Calls.py is using timit.py against the PythonFunctionCalls
test and Exceptions.py the TryRaiseExcept test.

Function calls are slower in 2.5, while try-except in 2.5 is
faster than 2.4.

I've attached the Calls.py file below.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  24 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
from pybench import Test

class PythonFunctionCalls(Test):

version = 2.0
operations = 5*(1+4+4+2)
rounds = 6

def test(self):

global f,f1,g,h

# define functions
def f():
pass

def f1(x):
pass

def g(a,b,c):
return a,b,c

def h(a,b,c,d=1,e=2,f=3):
return d,e,f

# do calls
for i in xrange(self.rounds):

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

def calibrate(self):

global f,f1,g,h

# define functions
def f():
pass

def f1(x):
pass

def g(a,b,c):
return a,b,c

def h(a,b,c,d=1,e=2,f=3):
return d,e,f

# do calls
for i in xrange(self.rounds):
pass

###

class BuiltinFunctionCalls(Test):

version = 2.0
operations = 5*(2+5+5+5)
rounds = 6

def test(self):

# localize functions
f0 = globals
f1 = hash
f2 = cmp
f3 = range

# do calls
for i in xrange(self.rounds):

f0()
f0()
f1(i)
f1(i)
f1(i)
f1(i)
f1(i)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)

f0()
f0()
f1(i)
f1(i)
f1(i)
f1(i)
f1(i)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)

f0()
f0()
f1(i)
f1(i)
f1(i)
f1(i)
f1(i)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Fredrik Lundh

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
>  thisother   diffthisother   diff
> ---
>PythonFunctionCalls:   130ms   108ms  +21.3%   132ms   109ms  
> +20.9%
> TryRaiseExcept:   115ms   137ms  -16.2%   129ms   140ms   
> -7.6%



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

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 apparent mistake.

>> Testnamesminimum run-timeaverage  run-time
>>  thisother   diffthisother   diff
>> ---
>>PythonFunctionCalls:   130ms   108ms  +21.3%   132ms   109ms  
>> +20.9%
>> TryRaiseExcept:   115ms   137ms  -16.2%   129ms   140ms   
>> -7.6%

(this=Python 2.5; other=Python2.4)

timeit.py results (see my last email), converted to the pybench
output:

 PythonFunctionCalls:   21.8ms   18.2ms  +19.8%
  TryRaiseExcept:   15.4ms   17.0ms   -9.4%

The timeit.py results for TryRaiseExcept on Python 2.4 vary
between 17.0 - 18.1ms. With Python 2.5 this doesn't happen.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  24 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symbol page for Language Reference Manual Index

2006-06-08 Thread A.M. Kuchling

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 
> format, if the idea is approved and someone else agrees to convert section 
> numbers to page links and do the necessary latex/html formatting (with a 
> Python script?).

There's a pool of volunteers for LaTeX formatting, so someone will
certainly handle that step.

> [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 
> appropriate regular index entry, such as
> http://docs.python.org/ref/parenthesized.html#l2h-342 for 5.2.3.  But I 
> will work this sort of thing out with whoever formats.]

It's probably easiest to make a list of symbols and the corresponding
section names and optionally a snippet of the paragraph that should be
the target of the link. Section numbers like 5.2.3 and link anchors
like #l2h-342 are generated by LaTeX2HTML and not visible when you're
editing the source text.

--amk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Fredrik Lundh

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, best of 3: 21.8 msec per loop

10 loops ?

what happens if you run the actual test code (the stuff inside the for 
loop) inside timeit, instead of running your test loop inside timeit?

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Fredrik Lundh

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 ?  (if it's not quite ready for public consumption, 
put it in the sandbox).



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symbol page for Language Reference Manual Index

2006-06-08 Thread engelbert . gruber

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 section numbers, in an agreed-on
>> format, if the idea is approved and someone else agrees to convert section
>> numbers to page links and do the necessary latex/html formatting (with a
>> Python script?).

> There's a pool of volunteers for LaTeX formatting, so someone will
> certainly handle that step.

would rst2docpy be of any help
(see http://docutils.sourceforge.net/sandbox/docpy-writer/)

although the text below doesnt sound like it could do it.

>> [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
>> appropriate regular index entry, such as
>> http://docs.python.org/ref/parenthesized.html#l2h-342 for 5.2.3.  But I
>> will work this sort of thing out with whoever formats.]
>
> It's probably easiest to make a list of symbols and the corresponding
> section names and optionally a snippet of the paragraph that should be
> the target of the link. Section numbers like 5.2.3 and link anchors
> like #l2h-342 are generated by LaTeX2HTML and not visible when you're
> editing the source text.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

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 sprint.

>> Tools/pybench> ~/projects/Python/Installation/bin/python Calls.py
>> 10 loops, best of 3: 21.8 msec per loop
> 
> 10 loops ?
> 
> what happens if you run the actual test code (the stuff inside the for 
> loop) inside timeit, instead of running your test loop inside timeit?

More or less the same results:

Python 2.4:

Tools/pybench> python Calls.py
10 loops, best of 3: 18.9 usec per loop
Tools/pybench> python Calls.py
10 loops, best of 3: 18.8 usec per loop
Tools/pybench> python Calls.py
10 loops, best of 3: 18.7 usec per loop

Python 2.5 (trunk as-of 2006-06-08):

Tools/pybench> ~/projects/Python/Installation/bin/python Calls.py
1 loops, best of 3: 22.9 usec per loop
Tools/pybench> ~/projects/Python/Installation/bin/python Calls.py
1 loops, best of 3: 23.7 usec per loop
Tools/pybench> ~/projects/Python/Installation/bin/python Calls.py
1 loops, best of 3: 23.4 usec per loop

I've attached the modified Call.py below so that you can
run it as well.

All this on AMD64, Linux2.6, gcc3.3.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
from pybench import Test

class PythonFunctionCalls(Test):

version = 2.0
operations = 5*(1+4+4+2)
rounds = 6

def test(self):

global f,f1,g,h

# define functions
def f():
pass

def f1(x):
pass

def g(a,b,c):
return a,b,c

def h(a,b,c,d=1,e=2,f=3):
return d,e,f

# do calls
for i in xrange(self.rounds):

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

f()
f1(i)
f1(i)
f1(i)
f1(i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
g(i,i,i)
h(i,i,3,i,i)
h(i,i,i,2,i,3)

def calibrate(self):

global f,f1,g,h

# define functions
def f():
pass

def f1(x):
pass

def g(a,b,c):
return a,b,c

def h(a,b,c,d=1,e=2,f=3):
return d,e,f

# do calls
for i in xrange(self.rounds):
pass

###

class BuiltinFunctionCalls(Test):

version = 2.0
operations = 5*(2+5+5+5)
rounds = 6

def test(self):

# localize functions
f0 = globals
f1 = hash
f2 = cmp
f3 = range

# do calls
for i in xrange(self.rounds):

f0()
f0()
f1(i)
f1(i)
f1(i)
f1(i)
f1(i)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)

f0()
f0()
f1(i)
f1(i)
f1(i)
f1(i)
f1(i)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)

f0()
f0()
f1(i)
f1(i)
f1(i)
f1(i)
f1(i)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f2(1,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,3,2)
f3(1,

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Fredrik Lundh

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 my machine, using timeit on the test 
bodies, I get noticeable speedups for both tests; from my earlier post:

function calls:

>  25 usec per loop for Python 2.4.3
>  22.5 usec per loop for Python 2.5 trunk

try/except:

>  15.1 usec per loop for Python 2.4.3
>  23.5 usec per loop for Python 2.5 alpha 2
>  11.6 usec per loop for Python 2.5 trunk

maybe the function call issue is an AMD64 thing?  or a compiler thing? 
do you see the same result on other hardware?

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Thomas Wouters

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 if I use the same compile options for 2.5 as for 2.4... ;-)-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

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 not slower here. At least, not if I use the
> same compile options for 2.5 as for 2.4... ;-)

I checked, both Python versions were compiled using these
options (and the same compiler):

# Compiler options
OPT=-DNDEBUG -g -O3 -Wall -Wstrict-prototypes
BASECFLAGS=  -fno-strict-aliasing

Perhaps it's a new feature in gcc 4.0 that makes the slow-down I see
turn into a speedup :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is "t#" argument format meant to be char buffer, or just read-only?

2006-06-08 Thread Brett Cannon

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, right?Nope; I was waiting to hear back on all of this; no committing of code that knowingly breaks tests and all.
> ==> ERROR: test_endian_double (ctypes.test.test_byteswap.Test)> --
> Traceback (most recent call last):>   File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line> 134, in test_endian_double> self.failUnlessEqual(bin(struct.pack("d", 
math.pi)), bin(s))>   File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 7, in bin> return hexlify(buffer(s)).upper()> TypeError: requested buffer type not available>
> Turns out the test does the following::>>   binascii.hexlify(buffer(ctypes.c_double(math.pi)))>> This is a problem because binascii.hexlify() uses "t#" as its argument> format string to PyArg_ParseTuple() and that fails now with a
> TypeError since ctypes.c_double (which subclasses ctypes._SimpleCData> which defines the buffer interface) does not have a char buffer> defined.>> Now this used to pass since buffer objects just used the read or write
> buffer in place of the char buffer, regardless if the wrapped object> had a char buffer function defined.>> But in checking out what "t#" did, I found a slight ambiguity in the> docs.  The docs say "read-only character buffer" for the short
> description, but "read-only buffer" for the longer description.  Which> is it?I am using binascii.hexlify(buffer(obj)) as a simple way to look at the bytes ofthe memory block.
I think that hexlify should be able to use any buffer object that hasa 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".Perhaps s# should be used instead since the docs say a read buffer can be used for that.
> Plus, Thomas, you might want to change _SimpleCData if you want it to> truly suport char buffers.I did not implement that because the memory block contains binary data,not text.
OK.-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] wsgiref doc draft; reviews/patches wanted

2006-06-08 Thread Joe Gregorio

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 frameworks need to know every detail..."
It doesn't offer any concrete information and just indirectly
 makes WSGI look complicated.

3. From the abstract:  "Having a standard interface makes it easy to use a
  WSGI-supporting application with a number of different web servers."

 is a little akward, how about:

"Having a standard interface makes it easy to use an application
that supports WSGI with a number of different web servers."

4. I believe the order of submodules presented is important and think that
   they should be listed with 'handlers' and 'simple_server' first:

wsgiref.handlers - server/gateway base classes
wsgiref.simple_server - a simple WSGI HTTP server
wsgiref.util - WSGI environment utilities
wsgiref.headers - WSGI response header tools
wsgiref.validate - WSGI conformance checker

5. You might consider moving 'headers' into 'util'. Of course, you could
go all the way in simplifying and move 'validate' in there too.

wsgiref.handlers - server/gateway base classes
wsgiref.simple_server - a simple WSGI HTTP server
wsgiref.util - WSGI environment utilities

Besides those nits it looks very good and will be a fine
addition to the core library.

   -joe

On 6/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I've finished my draft for the wsgiref documentation (including stuff I
> swiped from AMK's draft; thanks AMK!), and am looking for comments before I
> add it to the stdlib documentation.
>
> Source: http://svn.eby-sarna.com/svnroot/wsgiref/docs
> PDF:http://peak.telecommunity.com/wsgiref.pdf
> HTML:   http://peak.telecommunity.com/wsgiref_docs/
>
> My current plan is to make a hopefully-final release of the standalone
> version of wsgiref on PyPI, then clone that version for inclusion in the
> stdlib.
>
> The latest version of wsgiref in the eby-sarna SVN includes a new
> ``make_server()`` convenience function (addressing Titus' concerns about
> the constructor signatures while retaining backward compatibility) and it
> adds a ``wsgiref.validate`` module based on paste.lint.
>
> In addition to those two new features, tests were added for the new
> validate module and for WSGIServer.  The test suite and directory layout of
> the package were also simplified and consolidated to make merging to the
> stdlib easier.
>
> Feedback welcomed.
>
> ___
> Web-SIG mailing list
> [email protected]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: 
> http://mail.python.org/mailman/options/web-sig/joe.gregorio%40gmail.com
>

-- 
Joe Gregoriohttp://bitworking.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Thomas Wouters

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% speedup of your testcase in 2.5 compared to 2.4. 3.3 showed a 10% slowdown or so.Test-more'ly y'rs,-- Thomas Wouters <[EMAIL PROTECTED]
>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Georg Brandl

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) and both 2.95 and 4.0 
> show a 10-20% speedup of your testcase in 2.5 compared to 2.4. 3.3 
> showed a 10% slowdown or so.

Does 4.0 show a general slowdown on your test machines? I saw a drop
of average Pystones from 44000 to 4 and from 42000 to 39000 on
my boxes switching from GCC 3.4.6 to 4.1.1.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread M.-A. Lemburg

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) and both 2.95 and 4.0 show
> a 10-20% speedup of your testcase in 2.5 compared to 2.4. 3.3 showed a 10%
> slowdown or so.
> 
> Test-more'ly y'rs,

Looks like it's time to upgrade to SuSE 10.1, then :-)

Thanks for checking.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 08 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Benchmarks

2006-06-08 Thread Thomas Wouters

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, though (I'd have to make sure the machine is unloaded for a much longer period of time, and I don't have the time :)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found

2006-06-08 Thread Chris AtLee

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
by checking for inflateCopy() in the system zlib during the configure
step.

I'm not sure if this works when using the zlib library included with
python or not.

Cheers,
Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found

2006-06-08 Thread Georg Brandl

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.

> I've posted patch #1503046 to sourceforge which implements option #2
> by checking for inflateCopy() in the system zlib during the configure
> step.

Thank you! As this involves autotools magic, I hope Martin (who assigned
the patch to himself) can look over it instead of me.

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Some more comments re new uriparse module, patch 1462525

2006-06-08 Thread John J Lee

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 on SF:
>
> 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 on this).

John

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread skip

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 'cvs up -r r242'.  How
do I get a list of tags?  In cvs I'd do something like 'cvs log | less'.

Thx,

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] tarfile and unicode filenames in windows

2006-06-08 Thread Facundo Batista

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
ascii 7-bits.

But then I put a file in that directory that has a more strange name
(one with an "o" and a dash above it): Myō-ō.txt

Here, the tarfile can't find the file. This is the same limitation
that with listdir(), where I have to pass the directory name unicoded,
to the system be able to find it. So:

nomdir = unicode(sys.argv[1])
tar = tarfile.open("prueba.tar.bz2", "w:bz2")
tar.add(nomdir)
tar.close()

The problem is that when tarfile finds that name, it crashes:

Traceback (most recent call last):
  File "comprim.py", line 8, in ?
tar.add(nomdir)
  File "C:\python24\lib\tarfile.py", line 1239, in add
self.add(os.path.join(name, f), os.path.join(arcname, f))
  File "C:\python24\lib\tarfile.py", line 1232, in add
self.addfile(tarinfo, f)
  File "C:\python24\lib\tarfile.py", line 1297, in addfile
self.fileobj.write(tarinfo.tobuf())
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in
position 8: ordinal not in range(128)

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.

Thank you very much!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread Oleg Broytmann

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 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 'cvs up -r r242'.  How

   You have to know the branch URL and the revision number. Then do
svn co -r 242 http://svn.example.org/svnroot/branch/
   or
svn up -r 242

> do I get a list of tags?  In cvs I'd do something like 'cvs log | less'.

   Tags and branches in Subversion are just directories in the virtual SVN
filesystem. So you can use svn ls,
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.list.html

   or view the repository via ViewVC. These are python tags:
http://svn.python.org/view/python/tags/ . Here is the tag for 2.4.2:
http://svn.python.org/view/python/tags/r242/

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread Tim Peters

[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 I'd use something like 'cvs up -r r242'.  How
> do I get a list of tags?  In cvs I'd do something like 'cvs log | less'.

Second question first:

svn list svn+ssh://[EMAIL PROTECTED]/python/tags

s/tags/branches/ if you want a list of branches.  Note that there's
nothing special about tags or branches in SVN -- they're just
directories, with agreed-to-by-project-convention names.  That's why
you don't find any commands that treat tags or branches as distinct
concepts.

First question:

   cd to the root of your release24-maint checkout, then
   svn switch svn+ssh://[EMAIL PROTECTED]/python/tags/r242
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread skip

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread skip


>> 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:

Tim>cd to the root of your release24-maint checkout, then
Tim>svn 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

?

Thx,

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread Oleg Broytmann

On Thu, Jun 08, 2006 at 02:55:29PM -0500, [EMAIL PROTECTED] wrote:
> Tim>svn 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 without changing base URL. Commits
will go to the trunk (or whatever tag/branch it was before updating).
svn switch updates *and* switch the base URL - commits will go to the
tag/branch you are switching to.
   You can also merge some changes from another tag/branch:
svn merge -r 2112:2121 http://svn.example.org/svnroot/anotherbranch/
   (merge the diff between revisions 2121 and 2112 in anotherbranch into
the current working directory).

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Subversion repository question - back up to older versions

2006-06-08 Thread Oleg Broytmann

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 tree; svn switch
already has a working tree so it only needs to transfer the diff. Less
traffic...

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symbol page for Language Reference Manual Index

2006-06-08 Thread Terry Reedy


"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
>> appropriate regular index entry, such as
>> http://docs.python.org/ref/parenthesized.html#l2h-342 for 5.2.3.  But I
>> will work this sort of thing out with whoever formats.]
>
> It's probably easiest to make a list of symbols and the corresponding
> section names and optionally a snippet of the paragraph that should be
> the target of the link. Section numbers like 5.2.3 and link anchors
> like #l2h-342 are generated by LaTeX2HTML and not visible when you're
> editing the source text.

I looked at the ref latex source and realized that the indexes have no 
source themselves but are autogenerated from index markup like in the 
following:

\section{Function definitions\label{function}}
\indexii{function}{definition}
\stindex{def}

A function definition defines a user-defined function object (see
section~\ref{types}):
\obindex{user-defined function}
\obindex{function}

Section numbers will allow the lines to be sorted in section insertion 
point so the formatter does not have to jump around within and between the 
multiple latex source files.  So I need to put all the info for each entry 
on one line.  I'll let the formatter worry about which index tag to use or 
whether a new \syindex tag should be added, and how to make \index{{}} 
work.

Terry Jan Reedy



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] tarfile and unicode filenames in windows

2006-06-08 Thread Martin v. Löwis

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 report, but I doubt that helps much. To get this
to work, somebody would have to research on how precisely non-ASCII
file names are supposed to be encoded in a tarfile. I know Unix 2003
specifies something to this effect (in pax(1)), but somebody would have
to understand and implement that. As this is all fairly non-trivial,
and must also consider a lot of prior art, it is unlikely that something
will be done about it in the next years.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Tim Peters

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
test_support.TESTFN)
  File "C:\Code\python\lib\test\test_optparse.py", line 158, in assertParseFail
self.assertFalse("expected parse failure")
AssertionError

1 test OK.
1 test failed:
test_optparse
[23476 refs]

That also, using -w and -f, reproduces the bizarre HPPA behavior when
test_optparse is rerun in verbose mode (test_filetype_noexist passes
then, but test_version fails).

I have no idea why any of this is true, but there's good and bad news:
 reverting rev 46757 does _not_ make the problem go away.  So you're
off the hook, but we don't know who to crucify in your place ;-)

As to why the failure only showed up recently, I'm not sure, but
test_file must run before test_optparse, and it looks like the problem
goes away if "too many"(!) other tests intervene.  The Win2K buildbot
is unique in that test_file has been followed very soon by
test_optparse two builds in a row.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Brett Cannon

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
test_filetype_noexisttest_support.TESTFN)  File "C:\Code\python\lib\test\test_optparse.py", line 158, in assertParseFailself.assertFalse("expected parse failure")AssertionError
Different type of failure as well; if you look at the original failure it has to do with the help output having an extra newline. 

1 test OK.1 test failed:test_optparse[23476 refs]That also, using -w and -f, reproduces the bizarre HPPA behavior whentest_optparse is rerun in verbose mode (test_filetype_noexist passesthen, but test_version fails).
I have no idea why any of this is true, but there's good and bad news: reverting rev 46757 does _not_ make the problem go away.Actually, that run had two checkins; there was also 46755.  But when I ``svn update -r46754`` it still fails on my OS X laptop.  So still ain't my fault.  =)
 
  So you'reoff the hook, but we don't know who to crucify in your place ;-)Oh, we live in America; we have a list to pull from.  =) 

As to why the failure only showed up recently, I'm not sure, buttest_file must run before test_optparse, and it looks like the problemgoes away if "too many"(!) other tests intervene.  The Win2K buildbot
is unique in that test_file has been followed very soon bytest_optparse two builds in a row.We don't have any mechanism in place to record when we find tests failing in a row to always run them in that order until we fix it, do we?  Nor do we have a script to just continually check out older revisions in svn, compile, and test until the tests do pass, huh?
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Tim Peters

[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
>> test_support.TESTFN)
>>   File "C:\Code\python\lib\test\test_optparse.py", line 158, in
assertParseFail
>> self.assertFalse("expected parse failure")
>> AssertionError

[Brett]
> Different type of failure as well;

Not so.

> if you look at the original failure it has to do with the help output
> having an extra newline.

While if you look at the original failure ;-), you'll see that _both_
failure modes occur.  The one I showed above occurs when test_optparse
runs the first time; the one you're thinking of occurs when regrest
*re*runs test_optparse in verbose mode.  The original HPPA log
contained both failures.

>> ...
>> I have no idea why any of this is true, but there's good and bad news:
>> reverting rev 46757 does _not_ make the problem go away.

> Actually, that run had two checkins; there was also 46755.

Build 992 on the W2k trunk buildbot had only 46757 in its blamelist,
and was the first failing test run there.

> But when I ``svn update -r46754`` it still fails on my OS X laptop.

What revision was your laptop at before the update?  It could help a
lot to know the earliest revision at which this fails.

> So still ain't my fault.  =)

No, you're so argumentative today I'm starting to suspect it is ;-)

...

>> As to why the failure only showed up recently, I'm not sure, but
>> test_file must run before test_optparse, and it looks like the problem
>> goes away if "too many"(!) other tests intervene.  The Win2K buildbot
>> is unique in that test_file has been followed very soon by
>> test_optparse two builds in a row.

> We don't have any mechanism in place to record when we find tests failing in
> a row to always run them in that order until we fix it, do we?

That's right -- none.  If would be easy to check in a little temporary
tweak -- think I'll do that.

> Nor do we have a script to just continually check out older revisions
> in svn, compile, and test until the tests do pass, huh?

We don't, and I don't either.  IIRC, Neil did quite a bit of that some
time ago, and he may have a script for it.  Doing a binary search
under SVN should be very easy, given that a revision number identifies
the entire state of the repository.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Brett Cannon

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 1042, intest_filetype_noexist>> test_support.TESTFN)>>   File "C:\Code\python\lib\test\test_optparse.py", line 158, in
assertParseFail>> self.assertFalse("expected parse failure")>> AssertionError[Brett]> Different type of failure as well;Not so.> if you look at the original failure it has to do with the help output
> having an extra newline.While if you look at the original failure ;-), you'll see that _both_failure modes occur.  The one I showed above occurs when test_optparseruns the first time; the one you're thinking of occurs when regrest
*re*runs test_optparse in verbose mode.  The original HPPA logcontained both failures.Ah, my mistake. 
>> ...>> I have no idea why any of this is true, but there's good and bad news:>> reverting rev 46757 does _not_ make the problem go away.> Actually, that run had two checkins; there was also 46755.
Build 992 on the W2k trunk buildbot had only 46757 in its blamelist,and was the first failing test run there.> But when I ``svn update -r46754`` it still fails on my OS X laptop.What revision was your laptop at before the update?  It could help a
lot to know the earliest revision at which this fails.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. 
> So still ain't my fault.  =)No, you're so argumentative today I'm starting to suspect it is ;-)Sorry, but at the moment Python is failing on ``make install`` when it runs compileall . 
...>> As to why the failure only showed up recently, I'm not sure, but
>> test_file must run before test_optparse, and it looks like the problem>> goes away if "too many"(!) other tests intervene.  The Win2K buildbot>> is unique in that test_file has been followed very soon by
>> test_optparse two builds in a row.> We don't have any mechanism in place to record when we find tests failing in> a row to always run them in that order until we fix it, do we?That's right -- none.  If would be easy to check in a little temporary
tweak -- think I'll do that.> Nor do we have a script to just continually check out older revisions> in svn, compile, and test until the tests do pass, huh?We don't, and I don't either.  IIRC, Neil did quite a bit of that some
time ago, and he may have a script for it.  Doing a binary searchunder SVN should be very easy, given that a revision number identifiesthe entire state of the repository.That would be handy.  Question is do we just want a progressive backtrack or an actual binary search that goes back a set number of revisions and then begins to creep back up in rev. numbers when it realizes it has gone back too far.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Tim Peters

...

[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 "Revsion: N" line from "svn info"
output executed from the root of your checkout.  Or if you have the
Python executable handy:

>>> import sys
>>> sys.subversion
('CPython', 'trunk', '46762')

No, I'm not making that up!

>> ...
>> Doing a binary search under SVN should be very easy, given that
>> a revision number identifies the entire state of the repository.

> That would be handy.  Question is do we just want a progressive backtrack or
> an actual binary search that goes back a set number of revisions and then
> begins to creep back up in rev. numbers when it realizes it has gone back
> too far.

What we really want to do is solve the problem.  If we're going to tie
up my machine doing it, I want as few builds as theoretically
possible.  If we're going to tie up your machine, it's fine by me if
it goes back one checkin at a time until 1991 :-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Brett Cannon

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 work.A good clue is to look at the "Revsion: N" line from "svn info"output executed from the root of your checkout.  Or if you have thePython executable handy:
>>> import sys>>> sys.subversion('CPython', 'trunk', '46762')No, I'm not making that up!Oh,
I believe you.  Issue is that I did a svn update when I got home
today.  I have another checkout that I never modify (to use as a
reference checkout) that I have not updated since rev. 43738 and it
passes the tests.  That sure helps narrow it down, doesn't it.  =)  A
quick check of rev. 46750 has the test passing as well.
 >> ...>> Doing a binary search under SVN should be very easy, given that
>> a revision number identifies the entire state of the repository.> That would be handy.  Question is do we just want a progressive backtrack or> an actual binary search that goes back a set number of revisions and then
> begins to creep back up in rev. numbers when it realizes it has gone back> too far.What we really want to do is solve the problem.Of course. 

  If we're going to tieup my machine doing it, I want as few builds as theoreticallypossible.  If we're going to tie up your machine, it's fine by me ifit goes back one checkin at a time until 1991 :-)

=)  On my slow machine, it might be another 15 years before we get to current on HEAD.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Tim Peters

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 don't know what is ;-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Brett Cannon

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_ not a reason for using doctest, I don't know what is ;-)That's hilarious!  OK, that's it.  I am definitely focusing my efforts for 
2.6 in improving testing.-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

2006-06-08 Thread Tim Peters

[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 doctest, I don't know what is ;-)

[Brett]
> That's hilarious!  OK, that's it.  I am definitely focusing my efforts for
> 2.6 in improving testing.

LOL.  Believe it or not, we wouldn't have had a problem here if
doctest had been used instead -- but the reason isn't particularly
sane ;-)

Before the conversion, test_file.py ended with:

try:
bug801631()
finally:
os.unlink(TESTFN)

so that TESTFN got removed _no matter what_.  Some of the individual
tests here are careless about cleaning up after themselves, and that
last clause used to hide a multitude of lazy sins.  A doctest would
naturally also have ended with a "clean up the mess" block.

After the conversion to unittest, there was no final cleanup block,
and it just so happened that "testUnicodeOpen" has the alphabetically
largest test name, so unittest runs it last, and testUnicodeOpen() was
one of the lazy tests that didn't clean up after itself.

What that has to do with test_optparse is left as an exercise for the reader ;-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Some more comments re new uriparse module, patch 1462525

2006-06-08 Thread Mike Brown

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 on this).

Agreed.

Although you've added the test cases from 4Suite and credited me for them,
only a few of the test cases were invented by me.  I'd rather you credited
them to their original sources, as I did.

Also, I believe Graham Klyne has been adding some new cases to his Haskell
tools, but hasn't been updating the other spreadsheet and RDF files in which 
he publishes them in a more usable form. My tests only use what's in the 
spreadsheet, so I've only got 88 out of 99 "testRelative" cases from
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/tests/URITest.hs
So if you really want to be thorough, grab the missing cases from there.

-

It appears that Paul uploaded a new version of his library on June 3:
http://python.org/sf/1462525
I'm unclear on the relationship between the two now. Are they both up for 
consideration?

-

One thing I forgot to mention in private email is that I'm concerned that the
inclusion of URI reference resolution functionality has exceeded the scope of
this 'urischemes' module that purports to be for 'extensible URI parsing'.  It
is becoming a scheme-aware and general-purpose syntactic processing library
for URIs, and should be characterized as such in its name as well as in its
documentation. 

Even without a new name and more accurately documented scope, people are going
to see no reason not to add the rest of STD 66's functionality to it
(percent-encoding, normalization for testing equivalence, syntax
validation...). As you can see in Ft.Lib.Uri, the latter two are not at all
hard to implement, especially if you use regular expressions. These all fall 
under syntactic operations on URIs, just like reference-resolution.

Percent-encoding gets very hairy with its API details due to application-level
uses that don't jive with STD 66 (e.g. the fuzzy specs and convoluted history
governing application/x-www-form-urlencoded), the nuances of character
encoding and Python string types, and widely varying expectations of users.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] beta1 coming real soon

2006-06-08 Thread Neal Norwitz

It's June 9 in most parts of the world.  The schedule calls for beta 1
on June 14.  That means there's less than 4 days until the expected
code freeze.  Please don't rush to get everything in at the last
minute.  The buildbots should remain green to keep Anthony happy and
me sane (or is it the other way around).

If you plan to make a checkin adding a feature (even a simple one),
you oughta let people know by responding to this message.  Please get
the bug fixes in ASAP.  Remember to add tests!

I would really like it if someone on Windows could test the perf of
patch http://python.org/sf/1479611 and see if it improves perf.  I
will test again on Mac ppc, Linux x86, and Linux amd64 to verify gains

n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.5 issues need resolving in a few days

2006-06-08 Thread Neal Norwitz

The most important outstanding issue is the xmlplus/xmlcore issue.
It's not going to get fixed unless someone works on it.  There's only
a few days left before beta 1.  Can someone please address this?  If
that means reverting changes to maintain compatibility, so be it.

There is still the missing documentation for ctypes and element tree.
I know there's been progress on ctypes.  What are we going to do about
ElementTree?  Are we going to have another undocumented module in the
core or should we pull ET out (that would also fix the xml issue)?

Finally, there are the AST regressions.

If there are patches that address any of these issues, respond with a link here.

I'm guessing that all the possible features are not going to make it into 2.5.

n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

49 matches

Mail list logo