Re: [Python-Dev] Product function patch [issue 1093]
>> At one time Guido mentioned adding a built-in product() function to >> cover some of the remaining use cases of the built-in reduce(). Martin> What is the use case for product()? As I recall, there were basically two uses of reduce(), to sum a series or (less frequently) to take the product of a series. sum() obviously takes care of the first use case. product() would take care of the second. Skip ___ 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] Product function patch [issue 1093]
Actually, if you use Google code search, you'll find that multiplying the numbers in a list doesn't have much use at all. After summing numbers, joining strings is by far the most common usage -- which is much better done with the str.join() method. (PS. I rejected the issue; product() was proposed and rejected when sum() was originally proposed and accepted, and I don't see anything to change my mind.) On 9/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >> At one time Guido mentioned adding a built-in product() function to > >> cover some of the remaining use cases of the built-in reduce(). > > Martin> What is the use case for product()? > > As I recall, there were basically two uses of reduce(), to sum a series or > (less frequently) to take the product of a series. sum() obviously takes > care of the first use case. product() would take care of the second. > > Skip > > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Roundup issue mails "Do not thread!"
Hi all, Has anyone observed missing "email-threads" issue with Roundup bug tracker email? Any work around for that? I use mutt and find that roundup bug issue000xx mails are not being threaded. Its not do with settings, I believe. The issue000xxx emails might not being have In-Reply-To or References: header. Why are some msgs threaded and others not? You have some msgs which don't have correct In-Reply-To: References: headers (or not set at all) and you've turned on $strict_threads What do "->", "-?-" and "*>" mean in thread trees? When you turn off $strict_threads msgs with similar subjects get grouped together. In ... -- O.R.Senthil Kumaran http://uthcode.sarovar.org ___ 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] Porting information
Hi, I'm looking into porting CPython to native C# (not like IronPython) so that it can be used in game software on the XBox360: integrated with the indie development tool XNA Game Studio Express. I am looking for some guidance on how to approach this in the most effective way. I've started by looking at the parser portion of the code. However I am not certain this is the best place to start. Since there are so many ports I assume there is a well trodden path to completing this kind of task. Any suggestions would be greatly appreciated. I would prefer to break the task into portions that can be verified (tested for correctness) independently or as a stack (one on top of the next). That way I can catch errors early and have more confidence in what I am creating. When I looked through the test suites they all seem to be written in Python. Is there a test suite for the core of CPython i.e. before the C code can interpret Python code? Thanks, Ty ___ 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] Product function patch [issue 1093]
Ryan Freckleton wrote: > At one time Guido mentioned adding a built-in product() function to > cover some of the remaining use cases of the built-in reduce(). Speaking of such things, I was thinking the other day that it might be useful to have somewhere in the stdlib a full set of functions for doing elementwise operations and reductions on the built-in array type. This would make it possible for one to do efficient bulk arithmetic when the need arises from time to time without having to pull in a heavyweight dependency such as Numeric or 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] Roundup issue mails "Do not thread!"
> The issue000xxx emails might not being have In-Reply-To or References: header. If messages are entered through the web interface, they won't have these headers. Regards, Martin ___ 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] Roundup issue mails "Do not thread!"
* "Martin v. L?wis" <[EMAIL PROTECTED]> [2007-09-04 04:21:25]: > > The issue000xxx emails might not being have In-Reply-To or References: > > header. > > If messages are entered through the web interface, they won't have these > headers. Then I should file a bug/feature request for Roundup. How are others keeping track? Whenever I open an issue after analyzing the email message, I find that it salready discussed and state is changed, I had missed the further emails on the same issue due to non-threads. Thanks, -- O.R.Senthil Kumaran http://uthcode.sarovar.org ___ 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] Product function patch [issue 1093]
On 9/3/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Speaking of such things, I was thinking the other day > that it might be useful to have somewhere in the stdlib > a full set of functions for doing elementwise operations > and reductions on the built-in array type. > > This would make it possible for one to do efficient > bulk arithmetic when the need arises from time to time > without having to pull in a heavyweight dependency > such as Numeric or numpy. But what's the point, given that numpy already exists? Wouldn't you just be redoing the work that numpy has already done? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Roundup issue mails "Do not thread!"
> Then I should file a bug/feature request for Roundup. Please consider what you are asking for. How precisely should roundup set the In-reply-to header? It won't know what message this is a reply to, or whether it is a reply at all. > How are others keeping track? Whenever I open an issue after analyzing the > email > message, I find that it salready discussed and state is changed, I > had missed the further emails on the same issue due to non-threads. My email tool has better threading than yours, I guess. IceDove (Thunderbird) will thread the messages by subject also. The non-threaded ones get displayed on the second level, appearing in reply to the original message (or, rather, the youngest message with the same subject - just as if the message mentioned in In-Reply-To has already been deleted). Regards, Martin ___ 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] Porting information
> I've started by looking at the parser portion of the code. However I am > not certain this is the best place to start. Since there are so many > ports I assume there is a well trodden path to completing this kind of > task. I believe this assumption is wrong. There are not many ports, only a handful (or less - Jython, IronPython, PyPy). While Jython and IronPython may have similar implementation strategies, I would expect that PyPy took an entirely different approach. In any case, there certainly is a step that you apparently failed to perform as the very first step: set some explicit goals. What kind of compatibility do you want to achieve in your port, what other goals would you like to follow? IOW, why is IronPython not what you want (it *is* a port of CPython to C#, in a sense), and why is the C# support in PyPy not good enough for you? > I would prefer to break the task into portions that can be verified > (tested for correctness) independently or as a stack (one on top of the > next). That way I can catch errors early and have more confidence in > what I am creating. As I don't know what you want to achieve, it is difficult to tell you what steps to take. I assume your implementation would be similar to CPython in that it uses the same byte code format. So one path would be to ignore the compiler at all, and assume that the byte code format is given, i.e. start with port ceval.c. I'm not sure whether you also want to provide the same low-level API (i.e. whether you want to provide "Embedding and Extending"); it surely can't be the *same* API, since your's will be C#, whereas CPython's is, well, C. If you implement ceval.c, you will find quickly that you need much of the Objects folder, so implementing the 10 or so most important objects would be the natural starting point (type, int, string, tuple, dict, frame, code, class, method - assuming you would target Python 1.5 first, i.e. no bool, cell, descr, gen, iter, weakref, unicode, object). > When I looked through the test suites they all seem to be written in > Python. Is there a test suite for the core of CPython i.e. before the C > code can interpret Python code? Yes and no. The core Python is tested through compilation - if it compiles without warnings on the relevant compilers, it is considered good enough to run the Python test suite. For selected features of the interpreter, there are specific tests, in particular test_capi. The core of CPython (compiler, objects, builtins) is then tested through Python code. Regards, Martin ___ 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
