[Python-Dev] crash in 3.0b2 exception code
Hi,
I get a crash in one of lxml's doctests in 3.0b2, and it looks like it's
coming from plain Python code (as opposed to Cython code). Just a quick check
before I start digging into this, has anyone seen this before?
Stefan
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209997120 (LWP 15431)]
0x080f3b89 in BaseException_str (self=0x8d747d4) at Objects/exceptions.c:88
88 switch (PyTuple_GET_SIZE(self-args)) {
(gdb) bt
#0 0x080f3b89 in BaseException_str (self=0x8d747d4) at Objects/exceptions.c:88
#1 0x0805b158 in PyObject_Str (v=0x8d747d4) at Objects/object.c:414
#2 0x0807951a in unicode_new (type=0x81523a0, args=0x8de77ac, kwds=0x0) at
Objects/unicodeobject.c:9247
#3 0x0806068d in type_call (type=0x81523a0, args=0x8de77ac, kwds=0x0) at
Objects/typeobject.c:636
#4 0x080d83a9 in PyObject_Call (func=0x81523a0, arg=0x8de77ac, kw=0x0) at
Objects/abstract.c:2178
#5 0x0808de50 in PyEval_EvalFrameEx (f=0x8e2d07c, throwflag=0) at
Python/ceval.c:3606
#6 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2bf14, throwflag=0) at
Python/ceval.c:3481
#7 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2cef4, throwflag=0) at
Python/ceval.c:3481
#8 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2d4ec, throwflag=0) at
Python/ceval.c:3481
#9 0x08090f6b in PyEval_EvalCodeEx (co=0x8268458, globals=0xb7c182d4,
locals=0x0, args=0x8e2cea4, argcount=3, kws=0x8e2ceb0, kwcount=1,
defs=0x826c678, defcount=3, kwdefs=0x0,
closure=0x0) at Python/ceval.c:2830
[...]
___
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!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Hammond 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') Maybe this one is due to the fact that Windows, unlike POSIX, doesn't allow unlinking an open file? 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. Perhaps this is due to differing timer granularity on 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 That definitely shouldn't happen on Unix either. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiHfr+gerLs4ltQ4RAk5KAJ9It0Am1VfFNQNaE+wA8uWkkTZ6wQCgtwlx o16eVKpEXTHED4X1/Vi0Nk0= =zzKd -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
Re: [Python-Dev] bsddb: Test failures on windows (HELP!)
Tres Seaver wrote: Mark Hammond 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') Maybe this one is due to the fact that Windows, unlike POSIX, doesn't allow unlinking an open file? I see that some tests use os.unlink. They should use test_support.unlink() instead. -- Amaury Forgeot d'Arc ___ 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] lnotab and the AST optimizer
I'm making some good progress with the AST optimizer, and now the main thing standing in my way is lnotab. Currently lnotab expects bytecode sequencing to be roughly in-sync with the order of the source file and a few things that the optimizer does (e.g. swapping the bodies of an if/else after removing negation such that if not X: A; else: B becomes if X: B; else A) breaks this assumption. This will result in either an assertion failure or incorrect line numbers being reported. It seems that lnotab is used in relatively few places in the source code at the moment, but if I'm going to make a change to how lnotab works I want to do so in a way that's going to allow me to move forward while keeping everybody happy. I'm away for a few days so I probably won't be able to get back to anybody until either Sunday or Monday, but I'd appreciate it if anybody in the know can weigh in on this. Cheers, Tom ___ 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] lnotab and the AST optimizer
Hi, I'm making some good progress with the AST optimizer, and now the main thing standing in my way is lnotab. Currently lnotab expects bytecode sequencing to be roughly in-sync with the order of the source file and a few things that the optimizer does (e.g. swapping the bodies of an if/else after removing negation such that if not X: A; else: B becomes if X: B; else A) breaks this assumption. This will result in either an assertion failure or incorrect line numbers being reported. In http://bugs.python.org/issue2459 (speedup for / while / if with better bytecode) I had the same problem and decided to change the lnotab format so that line number increments are signed bytes rather than unsigned. The proposed patch contains many other changes, but with a bit of perseverance you may be able to extract the lnotab-related modifications... ;) This modification will allow many more types of control flow transformations than the current scheme does. By the way: swapping the bodies of an if/else after removing negation such that if not X: A; else: B becomes if X: B; else A) Is this really an optimization? if and if not should use the same number of opcodes (the former produces JUMP_IF_FALSE and the latter JUMP_IF_TRUE). Regards Antoine. ___ 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] lnotab and the AST optimizer
Antoine Pitrou solipsis at pitrou.net writes: In http://bugs.python.org/issue2459 (speedup for / while / if with better bytecode) I had the same problem and decided to change the lnotab format so that line number increments are signed bytes rather than unsigned. By the way, the same change could be done for relative jump offsets in the bytecode (change them from unsigned shorts to signed shorts). Taken together, both modifications would release a lot of constraints on the ordering of code blocks. ___ 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] lnotab and the AST optimizer
Antoine Pitrou wrote: Hi, Hi. Thanks for getting back to me so quickly. I can even respond before I have to drag myself off to bed. :) I'm making some good progress with the AST optimizer, and now the main thing standing in my way is lnotab. Currently lnotab expects bytecode sequencing to be roughly in-sync with the order of the source file and a few things that the optimizer does (e.g. swapping the bodies of an if/else after removing negation such that if not X: A; else: B becomes if X: B; else A) breaks this assumption. This will result in either an assertion failure or incorrect line numbers being reported. In http://bugs.python.org/issue2459 (speedup for / while / if with better bytecode) I had the same problem and decided to change the lnotab format so that line number increments are signed bytes rather than unsigned. The proposed patch contains many other changes, but with a bit of perseverance you may be able to extract the lnotab-related modifications... ;) This modification will allow many more types of control flow transformations than the current scheme does. Great, thanks! I'll check it out next week. By the way: swapping the bodies of an if/else after removing negation such that if not X: A; else: B becomes if X: B; else A) Is this really an optimization? if and if not should use the same number of opcodes (the former produces JUMP_IF_FALSE and the latter JUMP_IF_TRUE). Not quite. :) Even if we were producing a JUMP_IF_FALSE, it'd still be nice to optimize away the UNARY_NOT in the former. In practice, both actually produce a JUMP_IF_TRUE due to an existing optimization in the peephole optimizer which does just that. I'm trying to emulate this at the AST level because I'm part of a secret, evil conspiracy to be rid of the peephole optimizer. Shh. The relevant code in the peepholer, plus comment: /* Replace UNARY_NOT JUMP_IF_FALSE POP_TOP with withJUMP_IF_TRUE POP_TOP */ case UNARY_NOT: if (codestr[i+1] != JUMP_IF_FALSE || codestr[i+4] != POP_TOP || !ISBASICBLOCK(blocks,i,5)) continue; tgt = GETJUMPTGT(codestr, (i+1)); if (codestr[tgt] != POP_TOP) continue; j = GETARG(codestr, i+1) + 1; codestr[i] = JUMP_IF_TRUE; SETARG(codestr, i, j); codestr[i+3] = POP_TOP; codestr[i+4] = NOP; break; A little hackage with the dis module seems to confirm this is the case. Of course, if you know of a situation where this optimization doesn't apply and we actually wind up with a JUMP_IF_FALSE for an if/else post-peephole, I'm all ears. Thanks again! Cheers, T ___ 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] lnotab and the AST optimizer
Antoine Pitrou wrote: Antoine Pitrou solipsis at pitrou.net writes: In http://bugs.python.org/issue2459 (speedup for / while / if with better bytecode) I had the same problem and decided to change the lnotab format so that line number increments are signed bytes rather than unsigned. By the way, the same change could be done for relative jump offsets in the bytecode (change them from unsigned shorts to signed shorts). Taken together, both modifications would release a lot of constraints on the ordering of code blocks. ___ 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/tom%40vector-seven.com By the way, you were right about JUMP_IF_TRUE/JUMP_IF_FALSE. It's far too late. Apologies. I'm still pretty sure this is the peepholer's doing, though, and if that's the case then I want to try and deal with it at the AST level. Which is what's being achieved with the AST optimization I originally proposed, right? Cheers, T ___ 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!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesus Cea 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... I will be out of the city, 100% offline, until monday/tuesday. I will read your suggestions and do some tests as soon as possible. Please, keep the brainstorming going :) Feel free to (minimally };-)) touch the testcases trying to improve the situation. If that does the trick, please let me know to integrate the changes in my code. Remember this code must work in python 2.[3-6] (reason, for example, because I have my own test_support code, in pybsddb). Thanks a lot for your invaluable suggestions. - -- 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 iQCVAwUBSIinuplgi5GaxT1NAQK6qQP+LOv1lU6G6+GaSrxUqrnFM62bTcmXCMay S0ic3rWYUL4YTvWT/Ips/qBgYvRCPl3uHnmIDia9UAOnYh3EYjkFN+/4GDofGwM+ 1UBRu86C7LsYdJl2VlHJyHGWmz6tgbbtAue306CNX01yD+pwYsCUqMSTuzjiiNCx /q1DHdJv8Qo= =OpNx -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
Re: [Python-Dev] lnotab and the AST optimizer
Thomas Lee tom at vector-seven.com writes: By the way, you were right about JUMP_IF_TRUE/JUMP_IF_FALSE. It's far too late. Apologies. I'm still pretty sure this is the peepholer's doing, Yes indeed. Which is what's being achieved with the AST optimization I originally proposed, right? Well, not exactly, your optimization eliminates the UNARY_NOT by swapping the if/else blocks, while the peepholer eliminates the UNARY_NOT by fusing it with the subsequent jump opcode. In this case it doesn't make much of a difference, but if there is only an if without an else, the peepholer's optimization is still possible while yours is not. (bottom line: the peepholer is not dead!) cheers, Antoine. ___ 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] lnotab and the AST optimizer
Antoine Pitrou wrote: Thomas Lee tom at vector-seven.com writes: By the way, you were right about JUMP_IF_TRUE/JUMP_IF_FALSE. It's far too late. Apologies. I'm still pretty sure this is the peepholer's doing, Yes indeed. Which is what's being achieved with the AST optimization I originally proposed, right? Well, not exactly, your optimization eliminates the UNARY_NOT by swapping the if/else blocks, while the peepholer eliminates the UNARY_NOT by fusing it with the subsequent jump opcode. In this case it doesn't make much of a difference, but if there is only an if without an else, the peepholer's optimization is still possible while yours is not. Unless a pass is injected into the if body, which will generate no additional bytecode and still have the same net effect. (bottom line: the peepholer is not dead!) We'll see ;) Thanks for all your help, I'm looking forward to getting my hands on that patch. Cheers, T ___ 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] lnotab and the AST optimizer
At 12:56 AM 7/25/2008 +1000, Thomas Lee wrote: I'm making some good progress with the AST optimizer, and now the main thing standing in my way is lnotab. Currently lnotab expects bytecode sequencing to be roughly in-sync with the order of the source file and a few things that the optimizer does (e.g. swapping the bodies of an if/else after removing negation such that if not X: A; else: B becomes if X: B; else A) breaks this assumption. This will result in either an assertion failure or incorrect line numbers being reported. It seems that lnotab is used in relatively few places in the source code at the moment, but if I'm going to make a change to how lnotab works I want to do so in a way that's going to allow me to move forward while keeping everybody happy. I'm away for a few days so I probably won't be able to get back to anybody until either Sunday or Monday, but I'd appreciate it if anybody in the know can weigh in on this. I'd personally love it if the lnotab were capable of handling line numbers from different files as well as out-of-order lines. (For function inlining, among other more esoteric things.) ___ 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] [Python-3000] Removing bsddb module from py3k (was Re: No beta2 tonight)
On Mon, Jul 21, 2008 at 2:26 AM, Jesus Cea [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josiah Carlson wrote: | I'm still curious as to what deep features people are using in bsddb. | Anyone have any pointers to open source software? I'm using replication and distributed transactions. Database encryption and page integrity checks. Abusing the master election BDB infrastructure for some evil but fun purposes. Managing databases in the 200 terabyte range. Locking logging infrastructure to implement application logic integrated with database operation. MVCC everywhere. Nothing I can show you without killing you after, though. That's the kind of answer I was looking for :). Though I don't know if you are the typical user; I don't have enough data (the few others that sent messages here and privately weren't using it to your extent). Some of those features are possible to add without huge amounts of work (an afternoon or two), but indeed, some of those are not possible without substantial investment and testing. Independently of current bsddb usage profile, current 2.6 code support for distributed transactions and replication enables new application uses that sqlite can't match. Since I'm taking full responsability over bsddb both in 2.6 and 3.0, I don't really see what the issue is. Past mistakes and maintenance nightmares WILL NOT be repeated. Your taking over of maintenance is part of the reason why I withdrew my offer ;) . - 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
Greg Ewing said: I would actually be in favour of adding a matrix multiplication operator That would be helpful to me, for my students as well as my papers. 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
Sebastien Loisel wrote: Greg Ewing said: I would actually be in favour of adding a matrix multiplication operator That would be helpful to me, for my students as well as my papers. Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. There is no type(matrix). The notion of what makes a Python object a matrix is a convention and to have built-in operators dedicated to such objects makes no sense. There are multiple ways to stuff matrices into Python. Please submit a PEP for a type(matrix) first. Until a matrix is a first-order object in Python, there is no logic to making operators for them. -Scott -- Scott Dial [EMAIL PROTECTED] [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] Any PEP about 2.6 - 3000 code transition?
On Jul 21, 2008, at 22:37, Lennart Regebro 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'm working on getting a version of PyCXX working with Python 3.0. The lack of any docs outside of the header files is making this a slow process. I think its a mistake to expect a serious beta test of extensions when you have no guide to the changes in the C API. If you had a guide then diff it between releases would be a guide to what need fixing up going from beta to beta to rc. Oh and I'm not going to try and make a version of PyCXX that works on 2.x and 3.x as the changes are too fundamental. Barry ___ 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 Fri, Jul 25, 2008 at 12:06 AM, Scott Dial [EMAIL PROTECTED] wrote: Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. There is no type(matrix). The notion of what makes a Python object a matrix is a convention and to have built-in operators dedicated to such objects makes no sense. There are multiple ways to stuff matrices into Python. Please submit a PEP for a type(matrix) first. Until a matrix is a first-order object in Python, there is no logic to making operators for them. Though I would personally find a matrix multiplication operator useful, I have to agree with this. Anyway, it is easy to define pseudo-operators in Python; just create an Operator class and implement its __mul__ and __rmul__ methods appropriately (there are recipes for this around somewhere). Then you can define various custom multiplication operators with syntax like this: A *matrixmul* B A *dot* B A *cross* B A *elementwise* B Some other fun possibilities: A +concat+ B A /solve/ B A **left_inverse** (-1) A **right_inverse** (-1) x **tetrate** y n |choose| k Fredrik ___ 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] lnotab and the AST optimizer
Thomas Lee wrote: I'm making some good progress with the AST optimizer, and now the main thing standing in my way is lnotab. My suggestion would be to drop the idea of trying to compress the lnotab in clever ways, and just make it a straightforward list of bytecode offset/line number pairs. I can't imagine that the size of an uncompressed lnotab would be a problem in this day and age. If ordering is an issue, generate it internally as a dict and convert it to a sorted list on output. -- 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
Scott Dial wrote: Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. Why should that matter? We already have things like sum(), which operates on any sequence of numbers, without needing a special array of numbers data type. I don't see why one shouldn't be able to perform matrix multiplication on a plausible representation of a matrix using the existing built-in sequence types. Until a matrix is a first-order object in Python, there is no logic to making operators for them. If there were a dedicated matrix type, there would actually be *less* reason to have a new operator, since that type could just implement * as matrix multiplication. However, there are disadvantages to that, which become apparent when numpy is considered. There are good reasons for wanting * to mean elementwise multiplication of numpy arrays. There are also good reasons for wanting to use numpy arrays as matrices, since you get the benefit of all the other powerful things that numpy can do with arrays. You can use a matrix type that's based somehow on a numpy array, but there are problems with that too. E.g. if you add a matrix and a plain numpy array, what type should the result be? If plain numpy arrays can be used directly as matrices, that problem goes away. -- 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
Fredrik Johansson wrote: Anyway, it is easy to define pseudo-operators in Python; A *matrixmul* B A *dot* B A *cross* B A *elementwise* B Urg. This is another one of those recipes that I consider is too clever for its own good. Very nice in theory, but I would never use it in real life. What's more, it doesn't address the real problem at hand, which is providing a notation for matrix multiplication that is concise enough to be used *very* frequently -- like multiple times in every line of code that manipulates matrices. -- 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
Greg Ewing wrote: Scott Dial wrote: Perhaps I'm nobody, but I think this would be ridiculous. Matrices are not native objects to the language. Why should that matter? We already have things like sum(), which operates on any sequence of numbers, without needing a special array of numbers data type. I would argue that Python contains a array of some_type data type. That sum() performs a left-fold of __add__ on the array is completely independent of them being numbers. In all fact, they could be any type that supports __add__/__radd__ or even a mix of types. I do not believe array of numbers to be analogically equivalent to a matrix of numbers. We have an array of type in Python, we do not have a matrix of type in Python. sum() is not an operator, it is a builtin; the suggestion was for there to be an operator, not a builtin. If you want to suggest there be a mmul() builtin, then perhaps there is a viable answer there, despite the lack of a matrix of type still. I don't see why one shouldn't be able to perform matrix multiplication on a plausible representation of a matrix using the existing built-in sequence types. What is a plausible representation of a matrix? Is it a list of lists? Row-major (m[1][2]) or column-major (m[2][1])? Is it a dictionary of tuple'd indices (m[1,2])? Also, You went on to talk about wanting to using numpy.array. How does this not make it clear that there is not a case of TOOWTDI? -Scott -- Scott Dial [EMAIL PROTECTED] [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
On Thu, Jul 24, 2008 at 7:08 PM, Greg Ewing [EMAIL PROTECTED] wrote: Fredrik Johansson wrote: Anyway, it is easy to define pseudo-operators in Python; A *matrixmul* B A *dot* B A *cross* B A *elementwise* B Urg. This is another one of those recipes that I consider is too clever for its own good. Very nice in theory, but I would never use it in real life. That's unfortunate ;), because it's available in Python today, and with the common local caching of globals, can be as short as 3 characters (M for matrixmul, D for dot, X for cross, E for elementwise). What's more, it doesn't address the real problem at hand, which is providing a notation for matrix multiplication that is concise enough to be used *very* frequently -- like multiple times in every line of code that manipulates matrices. This is the first time anyone has mentioned conciseness in this thread. And what's a 3 character operator between friends? The and and not operators don't seem to be bothered by three characters. ;) - 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
[Python-Dev] Warnings for intra-package imports
I was just reading up on PEP 328. In the Timeline section, it mentions that intra-package imports should raise a DeprecationWarning in 2.6. This doesn't seem to be implemented currently. Is this still the plan? I would like to see Py3k warnings for these kinds of imports at least. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] Warnings for intra-package imports
On Thu, Jul 24, 2008 at 10:53 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: I was just reading up on PEP 328. In the Timeline section, it mentions that intra-package imports should raise a DeprecationWarning in 2.6. This doesn't seem to be implemented currently. Is this still the plan? I would like to see Py3k warnings for these kinds of imports at least. It should still be the plan. -Brett ___ 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
Scott Dial wrote: I would argue that Python contains a array of some_type data type. That sum() performs a left-fold of __add__ on the array is completely independent of them being numbers. That's not strictly true -- it explicitly refuses to operate on strings (or at least it did last time I heard). Guido has said that he *intends* it to only be used for numbers, even if it happens to accidentally do something with other types. However, as I envisage it, the @ operator wouldn't be restricted to numbers either -- it would do whatever the * and + operations do on the elements. sum() is not an operator, it is a builtin; the suggestion was for there to be an operator, not a builtin. That's true, and it means that the built-in implementation wouldn't have as wide applicability as the sum() function, since it would be restricted to lists and tuples (and perhaps array.array instances). But I don't think that's a fatal flaw -- if you create your own sequence type, you have to take steps if you want to be able e.g. to use + to concatenate them, and nobody complains about that. If you want to suggest there be a mmul() builtin, then perhaps there is a viable answer there No, that's not a viable answer to people who want a matrix multiplication operator. They want an operator because a function is nowhere near concise enough. Telling these people they have to use a function to multiply matrices is like telling them they have to use a function to multiply numbers. What is a plausible representation of a matrix? Is it a list of lists? That's one. A tuple of tuples would be another. Row-major (m[1][2]) or column-major (m[2][1])? Pick one and stick to it. Probably row-major, since it's what the numpy matrixmultiply function uses. Is it a dictionary of tuple'd indices (m[1,2])? I think dictionaries would have to be excluded, because there's no easy way of finding out the dimensions, it's not obvious what to do about missing elements, etc. Also, You went on to talk about wanting to using numpy.array. Yes -- what's wrong with that? How does this not make it clear that there is not a case of TOOWTDI? I think there *is* one obvious way of representing a matrix, or any 2D array, using built-in Python types, or rather two ways -- a list of lists if you want mutability, or a tuple of tuples if you want immutability. -- 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
Josiah Carlson wrote: This is the first time anyone has mentioned conciseness in this thread. I thought it more or less went without saying. After all, if conciseness isn't a goal, there's nothing wrong with a plain function call, which can be as short as 3 characters as well. The trouble is that, for the people who badly want a matrix multiplication operator, 3 characters is far too long! -- 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
