[Python-Dev] bsddb: Test failures on windows (HELP!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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... Details: http://www.python.org/dev/buildbot/all/x86%20XP-4%20trunk/builds/1364/step-test/0 Thanks in advance for your time and attention. Of course, any other help appreciated :-) - -- 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 iQCVAwUBSIdPJJlgi5GaxT1NAQLzFwP9E0huY63jOZWx9v/H7NhDGwIqFl5OGfhO EZ6uCdRBuyH4Y4jQBaIKTFN9jXu2sSONNMBDgOZznkBuYtFIA8Xmn9KDrkuZ5k8G 1GlcG+DcoG1aP1PANgrPMkEpptw5/TNBlA3s6p/F4oDSye1kMW0CbGcSHeECYF9R CIhZztqZvWk= =aZoO -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Infix operators
Dear Pythonistas, I've googled for this but I wasn't able to find anything definitive. I was recently looking at scipy to see if I could use it in stead of MATLAB for my class on numerical PDEs, but I noticed that there's some difficulty related to the notation; mainly, the matrix multiplication, and the linear solver (i.e., MATLAB's \ operator). After giving it some thought, I've decided to hold back for now and use MATLAB. Since scipy/numeric python have been around for a while and some of it is even integrated in Python 2.5, I'm sure this conversation has happened before, so please just educate me. Now I think that there's always going to be people wanting more and more operators in Python (although the operators I'm talking about are privileged -- the Chinese were using matrices some 2000 years ago), so I was thinking that it would be simpler to have a way for defining new infix operators, which would simply be binary functions whose names are punctuation marks; see any language with this feature, e.g., Haskell. Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? The one thing which I found was PEP 211 http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from James Rawlings. His comment about inv is completely absurd, and while he claims not to know \ and /, he is quoted as an authority on these operators. This particular PEP should probably be deleted from history. For a more authoritative explanation, a quick search yields MathWorks' own Loren Shure: http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. That absurdity aside, if I were a language designer, I would be reticent to add one operator to Python (like in PEP 211), because there will always be more operators that people want (how long until someone asks for an operator for the Kronecker product or the convolution?) But why not put in this infix possibility? Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Wed, Jul 23, 2008 at 2:14 PM, Sebastien Loisel [EMAIL PROTECTED] wrote: Dear Pythonistas, I've googled for this but I wasn't able to find anything definitive. I was recently looking at scipy to see if I could use it in stead of MATLAB for my class on numerical PDEs, but I noticed that there's some difficulty related to the notation; mainly, the matrix multiplication, and the linear solver (i.e., MATLAB's \ operator). After giving it some thought, I've decided to hold back for now and use MATLAB. Since scipy/numeric python have been around for a while and some of it is even integrated in Python 2.5, I'm sure this conversation has happened before, so please just educate me. Now I think that there's always going to be people wanting more and more operators in Python (although the operators I'm talking about are privileged -- the Chinese were using matrices some 2000 years ago), so I was thinking that it would be simpler to have a way for defining new infix operators, which would simply be binary functions whose names are punctuation marks; see any language with this feature, e.g., Haskell. Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? The one thing which I found was PEP 211 http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from James Rawlings. His comment about inv is completely absurd, and while he claims not to know \ and /, he is quoted as an authority on these operators. This particular PEP should probably be deleted from history. For a more authoritative explanation, a quick search yields MathWorks' own Loren Shure: http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/ Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. That absurdity aside, if I were a language designer, I would be reticent to add one operator to Python (like in PEP 211), because there will always be more operators that people want (how long until someone asks for an operator for the Kronecker product or the convolution?) But why not put in this infix possibility? Why not add the possibility for arbitrary infix operators? Others will most likely disagree with me, but I would claim that adding arbitrary infix operators are a great way to destroy readability. What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? In the module? In some other module that is imported? Can I override or do some pre-processing to the arguments and pass it on to the previously defined $ operator? So many questions, none of which tell me what '$' does. Really though, PEP 211 was a perfect example of a k-line function that someone attempted to make syntax that really didn't need to be syntax. And arguably, any infix operator will need to result in a lookup for the new infix operator, which will be as fast (or slow) as a globals lookup, so you may as well define your operator as a two-argument function, which has defined semantics, and can be imported and passed just like all functions defined for years. I would argue current operators are *convenience* for the 99%+ majority of mathematical operations done in Python, with well-defined and understood semantics in the 99%+ cases they are used for. Further, the addition of further infix operators are, strictly speaking, a domain-specific language, which Python (as a language) doesn't frown upon, but doesn't encourage either. If you still think that X \ Y would honestly make Python a better language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Dear Josiah, Thank you for your email. On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson [EMAIL PROTECTED] wrote: What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? In the module? In some other module that is imported? Can I override or do some pre-processing to the arguments and pass it on to the previously defined $ operator? So many questions, none of which tell me what '$' does. My question is really what the history of this thing is and what sort of opposition there is to this idea, in the python community. From your email, I suspect that this conversation has already taken place. I'm not going to become a python developer/politician and try to push this, my job involves teaching and research in mathematics and the programming language is just a tool. If I want to put food on my family (in the words of a wise man), I can't really spend a whole lot of time on this mailing list debating this. However, just for posterity (and I'm not going to pursue the argument further than this), I'll say this. The problem of determining the meaning (or overridability or whatever) of x=4$6 is the same as the problem of determining the meaning of x=fooz(4,6). Since it's not a good argument against user-defined functions, I don't see it as a good argument against user-defined operators. Of course, obviously the LISP people have decided that fooz(4,6) (or rather, (fooz 4 6)) is okay, and 4$6 is not, so who am I to dispute that. If you still think that X \ Y would honestly make Python a better Well, I'm not arguing for adding one more special-purpose operator, because probably the need for more operators will never end. If arbitrary operators were defined like ordinary functions, they could be brought in with the import numeric or whatever, and docstrings could be looked up, etc... language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. Thank you for the pointer. I have taken a look and it does look interesting, on first blush I would love to use that language. The main thing is that I worry about being out on the fringe, using a language that nobody uses, and which may get abandoned without warning (like Sun abandoned `self'), or be buggier just because people don't use it... Although I love metaprogramming and I would use it if it were in python, I don't really need to go that far (arbitrary infix operators would suffice to me.) Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?
As a data point, I just presented a tutorial here at OSCON on Python 3 Porting, and had a number of people asking about C API changes. I punted for my talk (*) because things are still in flux. Plus I only had 3 hours. I did suggest that if your extension is just glue to a C library, you should consider using ctypes. So yes, collecting this information, even if it's just in a wiki page, would be a good and popular thing. Anthony (*) slides: http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf On Mon, Jul 21, 2008 at 2:37 PM, Lennart Regebro [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 20:16, Brett Cannon [EMAIL PROTECTED] wrote: But waiting until all the betas have gone out totally defeats the purpose of the betas! I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now. But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Wed, Jul 23, 2008 at 4:48 PM, Sebastien Loisel [EMAIL PROTECTED] wrote: On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson [EMAIL PROTECTED] wrote: language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. Thank you for the pointer. I have taken a look and it does look interesting, on first blush I would love to use that language. The main thing is that I worry about being out on the fringe, using a language that nobody uses, and which may get abandoned without warning (like Sun abandoned `self'), or be buggier just because people don't use it... Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's in reasonably broad use and is actively maintained, and it allows user-defined infix operators. A programming language can't be all things to all people. That's why there's room in the world for more than one. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Dear Curt, Thank you for your email. Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's I have. I've considered a lot of languages, but OCaml isn't for me. My current language is MATLAB. Python is pretty close in syntax, and it's widely accepted, so you can teach students Python and they can go out and use it. You can also publish a paper and write a code snippet without having to explain the syntax. I'm not trying to go out on the blistering leading edge of computer language sophistication; that would not be good for my students, and it would not be good for my research. For most of my programs, what I need is a language where you don't need to give types or declare variables, because that just takes up space and obscures the math. So I need a mainstream dynamic language like Python or MATLAB. OCaml is not dynamic, and linear algebra in OCaml is a pain in the neck because of the explosion of the number of operators for various pairs of operand types. Sincerely, -- Sébastien Loisel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?
On Mon, Jul 21, 2008 at 2:37 PM, Lennart Regebro [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 20:16, Brett Cannon [EMAIL PROTECTED] wrote: But waiting until all the betas have gone out totally defeats the purpose of the betas! I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now. But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-) I am the nominal maintainer of the D programming language's bindings to the Python/C API.[1] Keeping on top of the changes in the C API is therefore of some interest to me. At the heart of these bindings is 3000 or so lines of D code containing the translated C headers. Adding the changes made in 3.0 (and 2.6, for that matter) will probably have to be done by hand. Any document detailing every change, from the broadest refactorings to the tiniest name-changes, will therefore be of invaluable assistance to me. Obviously, I don't plan on even starting this upgrade until the C API is nailed down and such a document exists. But any drafts, or even a bulleted list of changes, would at least give me an idea of the scope of what I'm in for. [1] http://pyd.dsource.org -Kirk McDonald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Sebastien Loisel wrote: Essentially, in almost all applications, inv(A) is entirely wrong. You can ask any numerical analyst who works with large problems, and they will confirm it. One of the main reason is that, even if A is sparse, inv(A) is full. This argues for a function such as solve(A, b). It doesn't argue for an infix operator. But why not put in this infix possibility? Guido is on record as opposing any kind of macros or other extensible syntax, and this probably comes under the same heading. Besides which there are technical difficulties, such as how the parser is supposed to know the precedence of these user-defined operators. To address your original problem, I believe that numpy comes with a matrix type that defines * as matrix multiplication. That's the usual Python solution to these kinds of things -- rather than invent a new operator, invent a new type that behaves the way you want. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Dear Greg, Thanks for your email. Guido is on record as opposing any kind of macros or other extensible syntax, and this probably comes under the same heading. Thanks, that's exactly what I was looking for when I asked: Now since this is such a simple idea, I'm guessing it occured to pythonistas at some point in 1992, and got voted down and that decision has now become scripture. Is that the case? Case closed. Sincerely, -- Sébastien Loisel PS: This argues for a function such as solve(A, b). It doesn't argue for an infix operator. I know, I was demolishing PEP 211, not trying to support my point. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Close PEP 211? (was Re: Infix operators)
Sebastien Loisel wrote: The one thing which I found was PEP 211 http://www.python.org/dev/peps/pep-0211/ This now has a status of deferred. Given that itertools.product(A,B) == ((x,y) for x in A for y in B) == the proposed 'A @ B' and given Guido's pronounced distaste for new infix, should this be closed? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
Josiah Carlson wrote: What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's a custom infix operator. But where is it defined? It's not quite as bad as that -- it would be defined by the relevant operator method on one of the operands. But a convention would be needed for mapping arbitary non- alphanumeric sequences to method names, and it's not obvious how to do that. But the main technical problem I see is that of precedence. It would have to be declared somehow, or a declaration imported from another module. If it's imported, then parsing a module can't be done in isolation any more, since it depends on the contents of other modules. Things could get very messy. Really though, PEP 211 was a perfect example of a k-line function that someone attempted to make syntax that really didn't need to be syntax. It looks like a case of someone wanting a matrix multiplication operator in numpy, and then hunting around for something to make it mean in Python. I would actually be in favour of adding a matrix multiplication operator, but I would make it mean matrix multiplication in Python as well, operating on anything that can be treated as a 2D sequence. Why matrix multiplication in particular? Because it's the one thing that you do all the time with matrices for which there isn't an available operator. I think this one addition could be justified on the grounds of very wide usage. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Close PEP 211? (was Re: Infix operators)
Terry Reedy wrote: Given that itertools.product(A,B) == ((x,y) for x in A for y in B) == the proposed 'A @ B' and given Guido's pronounced distaste for new infix, should this be closed? Would there likely be any support for an alternative PEP defining @ as matrix multiplication in both Python and numpy? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infix operators
On Wed, Jul 23, 2008, Sebastien Loisel wrote: [...] I was thinking that it would be simpler to have a way for defining new infix operators, [...] python-dev is the wrong place for this discussion. Please use either comp.lang.python or python-ideas. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! ___ Python-Dev mailing list Python-Dev@python.org 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!)
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')
Maybe an old test file isn't being nuked? Others of the form:
|self.assertTrue(time.time()timeout)
| AssertionError
which also look more related to the test suite than to Windows.
There are also lots of errors due to the environment having a unicode object
in it:
| test test_site failed -- Traceback (most recent call last):
| ...
| TypeError: environment can only contain strings
| test test_subprocess failed -- errors occurred; run in verbose mode for
details
| [Possibly the same error as below?]
| test test_sys failed -- Traceback (most recent call last):
| File ...\subprocess.py, line 817, in _execute_child
|startupinfo)
| TypeError: environment can only contain strings
* A couple of wsgi related errors, including one about the environment - but
this has more information:
AssertionError: AssertionError: Environmental variable LIB is not a string:
type 'unicode' (value: u'C:Program FilesMicrosoft Visual Studio
9.0VCLIB;C:Program FilesMicrosoft
SDKsWindowsv6.0Alib;c:program filesmicrosoft visual
studio .NET 2003vc7atlmfclib;c:program filesmicrosoft
visual studio .NET 2003vc7lib;c:program filesmicrosoft
visual studio .NET 2003vc7PlatformSDKlib;C:Program
FilesMicrosoft Visual Studio .NET 2003SDKv1.1Lib') !=
AssertionError: Headers (('Content-Type', 'text/plain')) must be of type
list: type 'tuple'
So LIB has a Unicode value - evn though it has no Unicode characters, and
was presumably in the environment Python inherited (but presumably was
initially a string).
I can't reproduce the Unicode errors: 'python test_sys.py' works and I
couldn't run a full test suite (see below). Python allows you to set
unicode objects in os.environ, so its possible part of the test suite is
modifying the environment.
I tried to run a full test, but it hangs in various places before test_sys
(bz2, multiprocessing), and I ended up giving up. This was on for either 32
or 64bits with the current trunk, but sadly I've no idea what could be
happening there :(
So it sounds like just tracking down how a unicode object is getting into
the environment will solve the vast majority of the errors - except for the
bsddb and wsgi ones, which don't look particularly Windows specific...
Hope that helps a bit...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
