Re: [Python-Dev] bsddb: Test failures on windows (HELP!)

2008-07-29 Thread Jesus Cea

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Amaury Forgeot d'Arc wrote:
| I see that some tests use os.unlink. They should use
| test_support.unlink() instead.

Old stuff. Fix just committed.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSI8gQ5lgi5GaxT1NAQJyHwQAiU6izAcI5eI3tizxWkvsw4MBRmQzlGNi
Ib+U/ZxuO9bqYOXZLqIQWkH2Ry1/Li7KeepVRehdkVlSnFEkWVXPhNofxvlXoQpl
Rt0T8aGJ1GhWkdojkWE7Ab2L8mdTCunHuVyiAQBagTET1E9iRnjrf5//XsRvd09Z
SUfPgEnvqv4=
=96Vt
-END PGP SIGNATURE-
___
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] Relocating Python

2008-07-29 Thread Lupusoru, Razvan A
Hello,

 

I am trying to get Python 2.5.2 working for an IA32 system. The
compilation is done on an Ubuntu 8.04.1 dev system. I am using a custom
gcc and ld specific to the IA32 system.

 

This is my makefile:

##

BUILD_DEST = /i686-custom-kernel

CC = $(BUILD_DEST)/bin/i686-linux-gcc

CPP = $(CC) -E

CXX = $(BUILD_DEST)/bin/i686-linux-g++

LD = $(BUILD_DEST)/bin/i686-linux-ld

PYTHONINSTALLPATH = $(BUILD_DEST)/usr

Export

 

all:

tar xzfv Python-2.5.2.tgz

./Python-2.5.2/configure -prefix=${PYTHONINSTALLPATH}
-host=i686-linux -enable-shared

cd Python-2.5.2

make

make install

##

 

Everything compiles correctly. I then copy the contents of the
$BUILD_DEST and put them on the hard drive for my IA32 system. I
basically use the contents of $BUILD_DEST as the root directory on my
IA32 system. Python seems to run correctly when I run it, but when I do
things like "import pysqlite", it cannot find it. Is there anything
special I have to do to relocate my python (since on my IA32 system it
runs from /usr/bin/python but it originally gets created in
${BUILD_DEST}/usr/bin/python)?

 

Thank you,

 

Razvan A. Lupusoru

___
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] Relocating Python

2008-07-29 Thread Casey Duncan

On Jul 29, 2008, at 12:56 PM, Lupusoru, Razvan A wrote:


Hello,

I am trying to get Python 2.5.2 working for an IA32 system. The  
compilation is done on an Ubuntu 8.04.1 dev system. I am using a  
custom gcc and ld specific to the IA32 system.


This is my makefile:
##
BUILD_DEST = /i686-custom-kernel
CC = $(BUILD_DEST)/bin/i686-linux-gcc
CPP = $(CC) –E
CXX = $(BUILD_DEST)/bin/i686-linux-g++
LD = $(BUILD_DEST)/bin/i686-linux-ld
PYTHONINSTALLPATH = $(BUILD_DEST)/usr
Export

all:
tar xzfv Python-2.5.2.tgz
./Python-2.5.2/configure –prefix=$ 
{PYTHONINSTALLPATH} –host=i686-linux –enable-shared

cd Python-2.5.2
make
make install
##

Everything compiles correctly. I then copy the contents of the  
$BUILD_DEST and put them on the hard drive for my IA32 system. I  
basically use the contents of $BUILD_DEST as the root directory on  
my IA32 system. Python seems to run correctly when I run it, but  
when I do things like “import pysqlite”, it cannot find it. Is there  
anything special I have to do to relocate my python (since on my  
IA32 system it runs from /usr/bin/python but it originally gets  
created in ${BUILD_DEST}/usr/bin/python)?


You'll want to pass configure the prefix where python will ultimately  
be installed, otherwise the paths used during make won't  make sense  
on the destination system. That said, pysqlite is not part of the  
stdlib, so your actual problem may have more to do with how you've  
installed it then anything. When you run python once relocated, what  
does os.path contain?


What we do for packaging, is run 'configure' normally and then 'make',  
then override some make variables for 'make install' to temporarily  
install it in a different place for package staging. It looks  
something like this:


./configure && \
make && \
make BINDIR=$(shell pwd)/path/to/tmp/bin \
 CONFINCLUDEDIR=$(shell pwd)/path/to/tmp/include \
 INCLUDEDIR=$(shell pwd)/path/to/tmp/include \
 LIBDIR=$(shell pwd)/path/to/tmp/lib \
 MANDIR=$(shell pwd)/path/to/tmp/man \
 SCRIPTDIR=$(shell pwd)/path/to/tmp/lib \
 install

Then when the package is deployed, the files are actually installed  
under the standard 'configure' prefix (/usr/local I think).


hth,

-Casey
___
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] Deprecate parser's "ast" functions?

2008-07-29 Thread Guido van Rossum
+1 as well.

On Mon, Jul 21, 2008 at 7:47 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 3:13 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> The parser module exports each function and type twice, once with "AST" in
>> the name, once with "ST".  Since "AST" now has a different meaning for
>> Python code compilation, I propose to deprecate the "ast" variants in 2.6
>> and remove them in Python 3000.
>
> +1 This personally has confused me!
>
>>
>> (Also, all keyword arguments are called "ast", that cannot change in 2.6
>> but should in 3.0.)
>>
>> I'm at the moment changing the documentation of parser to only refer to
>> the "st" variants anymore.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] fileobj.read(float): warning or error?

2008-07-29 Thread Guido van Rossum
On Mon, Jul 21, 2008 at 10:37 PM, Cameron Simpson <[EMAIL PROTECTED]> wrote:
> Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
> exception if asked for < 1 bytes? Or is there a legitimate use for read(0)
> with which I was not previously aware?

Indeed. read(0) is quite often generated as an edge case when one is
computing buffer sizes, and returning an empty string is most
definitely the right thing to do here (otherwise some application code
becomes more complex by having to avoid calling read(0) at all).

Of course, read(), read(None), read(-1) and read()
should all read all data until EOF.

On the main topic here, read() and read() should definitely raise an exception in
3.0. In 2.6 it should show a warning as it does in 2.5.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Matrix product

2008-07-29 Thread Guido van Rossum
On Fri, Jul 25, 2008 at 6:50 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Sebastien Loisel wrote:
>
>> What are the odds of this thing going in?
>
> I don't know. Guido has said nothing about it so far this
> time round, and his is the only opinion that matters in the
> end.

I'd rather stay silent until a PEP exists, but I should point out that
last time '@' was considered as a new operator, that character had no
uses in the language at all. Now it is the decorator marker. Therefore
it may not be so attractive any more.

I understand that you can't use A*B as matrix multiplication because
it should mean elementwise multiplication instead, just like A+B is
elementwise addition (for matrixes, as opposed to Python sequences).

But would it be totally outlandish to propose A**B for matrix
multiplication? I can't think of what "matrix exponentiation" would
mean...

--Guido

> I may write a PEP about this. However, since yesterday I've
> realised that there's a rather serious problem with part
> of my proposal.
>
> The problem is that being able to multiply matrices isn't
> much use without also being able to add them and multiply
> them by numbers, which obviously can't work with the
> built-in sequence types, since they already have other
> meanings for + and *.
>
> However, I still think that adding an @ operator for numpy
> to use is a good idea. So I'm now suggesting that the
> operator be added, with the intended meaning of matrix
> multiplication, but that no implementation of it be
> provided in core Python.
>
> There is a precedent for this -- the ellipsis notation was
> added purely for use by Numeric and its successors, and
> nothing in core Python attaches any meaning to it.
>
>> How do the PEPs work?
>
> Someone writes a PEP. People talk about it. Eventually, Guido
> either accepts it or rejects it (although in some cases it
> is an infinitely long time before that happens:-).
>
> --
> Greg
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] bsddb: Test failures on windows (HELP!)

2008-07-29 Thread Guido van Rossum
On Wed, Jul 23, 2008 at 10:44 PM, Mark Hammond
<[EMAIL PROTECTED]> wrote:
>> Trent, I was wondering if you could look at some test failures in MS
>> Windows builds. I can't debug Windows issues myself :-(. This is a MS
>> free environment...
>
> In these errors I see lots of bsdbd errors, many of the form:
>
> | DBFileExistsError: (17, 'File exists -- __fop_file_setup:  Retry limit
> (100) exceeded')

I've had this a few times in the past (Retry limit (100) exceeded)and
it has always been caused by cruft left behind by a previous run of
the test that didn't end well. Somehow these tests do not do a good
job of cleaning up old cruft before they run.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Matrix product

2008-07-29 Thread Sidnei da Silva
On Tue, Jul 29, 2008 at 9:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But would it be totally outlandish to propose A**B for matrix
> multiplication? I can't think of what "matrix exponentiation" would
> mean...

Before even reading this paragraph, A**B came to my mind, so I suspect
it would be the most intuitive option.

-- 
Sidnei da Silva
Enfold Systems http://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
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] Matrix product

2008-07-29 Thread Sebastien Loisel
Dear Guido,

Thank you for your email.

On Tue, Jul 29, 2008 at 8:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But would it be totally outlandish to propose A**B for matrix
> multiplication? I can't think of what "matrix exponentiation" would
> mean...

Right now, ** is the pointwise power:

>>> from numpy import *
>>> A=array([[1,2],[3,4]])
>>> print(A**A)
[[  1   4]
 [ 27 256]]

Since all the scalar operators have meaning as pointwise operator,
like you say it's hard to bump one off to give it to the matrix
product instead. I don't know if it's a good idea with **, it will
destroy the orthogonality of the system.

They used to say, ignore LISP at your own peril. In that spirit, let
me describe MATLAB's approach to this. It features a complete suite of
matrix operators (+-*/\^), and their pointwise variants (.+ .- ./ .*
.^), although + and .+ are synonyms, as are - and.-. Right now,
numpy's *,**,/ correspond to MATLAB .*,.^,./.

MATLAB implements scalar^matrix, matrix^scalar, but not matrix^matrix
(although since log and exp are defined, I guess you could clobber
together a meaning for matrix^matrix). Since ^ is the matrix-product
version of "power", 2^A may not be what you expect:

>> 2^A
   10.4827   14.1519
   21.2278   31.7106

Sincerely,

-- 
Sébastien Loisel
___
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] Matrix product

2008-07-29 Thread Fredrik Johansson
On Wed, Jul 30, 2008 at 2:26 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 6:50 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Sebastien Loisel wrote:
>>
>>> What are the odds of this thing going in?
>>
>> I don't know. Guido has said nothing about it so far this
>> time round, and his is the only opinion that matters in the
>> end.
>
> I'd rather stay silent until a PEP exists, but I should point out that
> last time '@' was considered as a new operator, that character had no
> uses in the language at all. Now it is the decorator marker. Therefore
> it may not be so attractive any more.

I don't like @.

> I understand that you can't use A*B as matrix multiplication because
> it should mean elementwise multiplication instead, just like A+B is
> elementwise addition (for matrixes, as opposed to Python sequences).
>
> But would it be totally outlandish to propose A**B for matrix
> multiplication? I can't think of what "matrix exponentiation" would
> mean...

http://mathworld.wolfram.com/MatrixExponential.html :-)

In fact Mathematica uses ** to denote general noncommutative
multiplication (though . for matrix multiplication in particular).
However, this wouldn't solve the problem, because an important reason
to introduce a matrix multiplication operator is to distinguish
between matrix and elementwise operations for arrays. The ** operator
already denotes the obvious elementwise operation in numpy.

Further, while A**B is not so common, A**n is quite common (for
integral n, in the sense of repeated matrix multiplication). So a
matrix multiplication operator really should come with a power
operator cousin.

Matlab uses * for matrix and .* for elementwise multiplication.
Introducing .* for elementwise multiplication in Python would not be
compatible with existing numpy code, and introducing .* with the
reversed meaning of Matlab would be *very* confusing :-)

Maple uses &* for matrix multiplication. However, Maple's syntax is
not a good style reference for anything.

Besides those alternatives and the regular *, I don't know any other
ASCII operators used by existing mathematical software for matrix
multiplication. Well, Fortress probably has some unicode symbol for it
(I suppose that would be one desperate possibility).

Fredrik
___
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] Matrix product

2008-07-29 Thread Greg Ewing

Guido van Rossum wrote:


last time '@' was considered as a new operator, that character had no
uses in the language at all. Now it is the decorator marker.


The only alternatives left would seem to be ?, ! or $,
none of which look particularly multiplicationish.


But would it be totally outlandish to propose A**B for matrix
multiplication? I can't think of what "matrix exponentiation" would
mean...


But ** has the same problem -- it already represents
an elementwise operation on numpy arrays.

--
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] Matrix product

2008-07-29 Thread Greg Ewing

Sebastien Loisel wrote:

let
me describe MATLAB's approach to this. It features a complete suite of
matrix operators (+-*/\^), and their pointwise variants (.+ .- ./ .*
.^)


That was considered before as well, but rejected on
the grounds that the dot-prefixed operators were too
cumbersome to use heavily.

In MATLAB, the elementwise operations are probably
used fairly infrequently. But numpy arrays are often
used to vectorise what are otherwise scalar operations,
in which case elementwise operations are used almost
exclusively.

--
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] Matrix product

2008-07-29 Thread Greg Ewing

Fredrik Johansson wrote:


Further, while A**B is not so common, A**n is quite common (for
integral n, in the sense of repeated matrix multiplication). So a
matrix multiplication operator really should come with a power
operator cousin.


Which obviously should be @@ :-)


Well, Fortress probably has some unicode symbol for it
(I suppose that would be one desperate possibility).


I've been carefully refraining from suggesting that.
Although now that unicode is allowed in identifiers,
it's not *quite* as heretical as it used to be.

--
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] Matrix product

2008-07-29 Thread Sebastien Loisel
Dear Greg,

Thank you for your email.

> In MATLAB, the elementwise operations are probably
> used fairly infrequently. But numpy arrays are often
> used to vectorise what are otherwise scalar operations,
> in which case elementwise operations are used almost
> exclusively.

Your assessment of pointwise operators in MATLAB is incorrect. The
pointwise operators in MATLAB are used heavily to vectorise the scalar
operations, exactly the same as what you describe in numpy. Recently,
the MATLAB JIT has become good enough that looping is fast, however,
the pointwise operators remain "the MATLAB way" of programming.

-- 
Sébastien Loisel
___
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