[Python-Dev] Threaded asynchronous return from functions
Short version: Could we get def funct( args ): if args == 'good': return 'good' async_return "I'll think about it" if args == '123': do_x() elif args == 'abc': do_y() else: do_z() as equivalent to def do_thinking( args ): if args == '123': do_x() elif args == 'abc': do_y() else: do_z() def funct( args ): if args == 'good': return 'good' t = threading.Thread(target=do_thinking, args=args) t.start() return "I'll think about it" Longer version: I have been doing some multithreaded work lately and have found that often what I find wanting to do is to call a function, have it check it's arguments, possibly do some work and then return to the caller, but still do some extra processing right after that. Currently to accomplish such feat I need to separate the 'extra processing' bit into a separate function and call that in a separate thread. A nice convenience would be a function or statement that would allow to return a value from the current function, but still keep running its code (in a separate thread). Such approach could then be used in many places where async processing is required, such as GUI programming, XMLRPC, web applications, ... with less boilerplate and more obvious code flow. -- Best regards, Aigars Mahinovs mailto:[email protected] #--# | .''`. Debian GNU/Linux (http://www.debian.org) | | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `' Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# ___ 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] Threaded asynchronous return from functions
Hello, 2011/7/4 Aigars Mahinovs > I have been doing some multithreaded work lately and have found that often what I find wanting to do is to call a function, have it check > it's arguments, possibly do some work and then return to the caller, > but still do some extra processing right after that. Currently to > accomplish such feat I need to separate the 'extra processing' bit > into a separate function and call that in a separate thread. A nice > convenience would be a function or statement that would allow to > return a value from the current function, but still keep running its > code (in a separate thread). Such approach could then be used in many > places where async processing is required, such as GUI programming, > XMLRPC, web applications, ... with less boilerplate and more obvious > code flow. > This kind of topic is not suitable to python-dev. Please ask this on the python-list mailing list, or eventually on python-ideas. (where someone will probably suggest you to use a nested function) Cheers, -- Amaury Forgeot d'Arc ___ 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] AUTO: Jon K Peck is out of the office (returning 07/15/2011)
I am out of the office until 07/15/2011. I am out of the office traveling Monday July 4 through Friday, July 15 I will have little or no access to email during this time, so I will be delayed in responding. Note: This is an automated response to your message "Python-Dev Digest, Vol 96, Issue 6" sent on 7/4/11 0:27:26. This is the only notification you will receive while this person is away.___ 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] Speed.Python.org
Now that we have the machine, we need to start working on collecting/organizing the resources needed to get a shared codespeed system in place. After speaking with various people, we felt that overloading codespeed-dev, pypy-dev or python-dev with the discussions around this would be sub optimal. I've spun up a new mailing list here: http://mail.python.org/mailman/listinfo/speed Those who are interested in working on or contributing to the speed.python.org project can subscribe there. I personally can not lead the project, and so I will be looking to the current speed.pypy.org team, and python-dev contributors for leadership in this. I got you the hardware and hosting! :) jesse ___ 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] cpython: Issue #12469: replace assertions by explicit if+raise
On Mon, 04 Jul 2011 18:06:53 +0200 victor.stinner wrote: > http://hg.python.org/cpython/rev/7eef821ab20d > changeset: 71197:7eef821ab20d > user:Victor Stinner > date:Mon Jul 04 18:06:35 2011 +0200 > summary: > Issue #12469: replace assertions by explicit if+raise Instead of generic Exception, it would be better to use AssertionError. Regards Antoine. ___ 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] cpython: Issue #12469: replace assertions by explicit if+raise
Am 04.07.2011 18:23, schrieb Antoine Pitrou: > On Mon, 04 Jul 2011 18:06:53 +0200 > victor.stinner wrote: >> http://hg.python.org/cpython/rev/7eef821ab20d >> changeset: 71197:7eef821ab20d >> user:Victor Stinner >> date:Mon Jul 04 18:06:35 2011 +0200 >> summary: >> Issue #12469: replace assertions by explicit if+raise > > Instead of generic Exception, it would be better to use AssertionError. What is the reason for this change anyway -- as far as I can see this code is never run with -O. Also I don't see how it relates to #12469. 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
[Python-Dev] [RELEASED] Python 3.2.1 rc 2
On behalf of the Python development team, I am pleased to announce the second release candidate of Python 3.2.1. Python 3.2.1 will the first bugfix release for Python 3.2, fixing over 120 bugs and regressions in Python 3.2. For an extensive list of changes and features in the 3.2 line, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2.1 visit: http://www.python.org/download/releases/3.2.1/ This is a testing release: Please consider trying Python 3.2.1 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) ___ 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] cpython: Issue #12469: replace assertions by explicit if+raise
On Mon, Jul 4, 2011 at 9:23 AM, Antoine Pitrou wrote: > On Mon, 04 Jul 2011 18:06:53 +0200 > victor.stinner wrote: > > http://hg.python.org/cpython/rev/7eef821ab20d > > changeset: 71197:7eef821ab20d > > user:Victor Stinner > > date:Mon Jul 04 18:06:35 2011 +0200 > > summary: > > Issue #12469: replace assertions by explicit if+raise > > Instead of generic Exception, it would be better to use AssertionError. > or in many cases given this was in unittests... use the self.assertFoo methods and avoid assert and if statements all together. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.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] cpython: Issue #12469: replace assertions by explicit if+raise
Le lundi 04 juillet 2011 à 18:23 +0200, Antoine Pitrou a écrit : > On Mon, 04 Jul 2011 18:06:53 +0200 > victor.stinner wrote: > > http://hg.python.org/cpython/rev/7eef821ab20d > > changeset: 71197:7eef821ab20d > > user:Victor Stinner > > date:Mon Jul 04 18:06:35 2011 +0200 > > summary: > > Issue #12469: replace assertions by explicit if+raise > Instead of generic Exception, it would be better to use AssertionError. and > or in many cases given this was in unittests... use the self.assertFoo > methods and avoid assert and if statements all together. The code is running in a subprocess (python -c ...), not in an unittest.TestCase, so I cannot use self.assertFoo and it doesn't really matter if the exception is an Exception or an AssertionError. > What is the reason for this change anyway -- as far as I can > see this code is never run with -O. I'm not sure that the code will never be running using -O, so I prefer to use an explicit if+raise. I don't like the assert statement because it doesn't provide any information about the failure (content of the variables) by default. Victor ___ 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] PEP 397 (Python launcher for Windows) reference implementation
On Mon, Jul 4, 2011 at 2:27 AM, Mark Hammond wrote: > While that makes alot of sense, the fact we are already "broken" in exactly > the same way means I hope we can treat the restoration of associations as a > separate issue - a worthwhile one, but not a pre-requisite for this PEP > being approved. I agree let the restoration or not of file association be an implementation detail and not a requirement. I also agree with Paul Moore that py.exe should be a separate install/uninstall It can be bundled with the python MSI but should be a standalone MSI that the python MSI executes. So uninstalling the version of python that installed it alone is not enough to remove it. This will make it seem like the file associations are just working for naive users but will still let them remove the associations. We can just put a warning in the uninstall process of py.exe that lets the user know if they still have python versions installed they will need to re-install them to get the file association again. ___ 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] Issue10403 - using 'attributes' instead of members in documentation
On Tue, Jun 28, 2011 at 10:30:14AM +1000, Nick Coghlan wrote: > Rather than fighting that convention, we should probably just confront > the ambiguity head on and update > http://docs.python.org/dev/glossary.html#term-attribute to describe > both uses of the term (and add a separate entry for "data attribute", > with a definition which basically says "attributes which are not > methods"). http://bugs.python.org/issue12491 is the issue to track it. The glossary term should give us a stance on what is meant by attributes. For the other issue (10403), I just concentrated on removing the term members and used attributes and methods appropriately focussing on clarity rather than presenting the detail on the object model. For our rescue, sphinx reST provide :attr: for attribute and :meth: for methods. :) -- Senthil ___ 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] PEP 397 (Python launcher for Windows) reference implementation
Mark Hammond gmail.com> writes: > > It might be better to look in the registry for other Python > > installations and ask the user which one to restore if there > > is more than one. Trying to restore the "last" one would be > > prone to breakage if the user didn't uninstall versions in > > precisely the reverse of the order of installation. > > While that makes alot of sense, the fact we are already "broken" in > exactly the same way means I hope we can treat the restoration of > associations as a separate issue - a worthwhile one, but not a > pre-requisite for this PEP being approved. I agree, but there's one aspect of associations which is perhaps worth exploring: the installation of a pre-3.3 version of Python after Python 3.3 is installed with the launcher will, if the user selects "Register Extensions", hijack the laumcher's associations to that earlier Python. Then bye bye launcher - how do we deal with that? Or don't we? There'll be no warning for the user, and this problem will occur even if the launcher is packaged separately from Python. so I think we need to think about this a little more. What say? Regards, Vinay Sajip ___ 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] cpython: Remove mention of medical condition from the test suite.
If you're going to get rid of the pun, you might as well change the
whole sentence...
On Sun, Jul 3, 2011 at 1:22 PM, georg.brandl wrote:
> http://hg.python.org/cpython/rev/76452b892838
> changeset: 71146:76452b892838
> parent: 71144:ce52310f61a0
> user: Georg Brandl
> date: Sun Jul 03 19:22:42 2011 +0200
> summary:
> Remove mention of medical condition from the test suite.
>
> files:
> Lib/test/test_csv.py | 8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>
> diff --git a/Lib/test/test_csv.py b/Lib/test/test_csv.py
> --- a/Lib/test/test_csv.py
> +++ b/Lib/test/test_csv.py
> @@ -459,20 +459,20 @@
> '5', '6']])
>
> def test_quoted_quote(self):
> - self.readerAssertEqual('1,2,3,"""I see,"" said the blind man","as he
> picked up his hammer and saw"',
> + self.readerAssertEqual('1,2,3,"""I see,"" said the happy man","as he
> picked up his hammer and saw"',
> [['1', '2', '3',
> - '"I see," said the blind man',
> + '"I see," said the happy man',
> 'as he picked up his hammer and saw']])
>
> def test_quoted_nl(self):
> input = '''\
> 1,2,3,"""I see,""
> -said the blind man","as he picked up his
> +said the happy man","as he picked up his
> hammer and saw"
> 9,8,7,6'''
> self.readerAssertEqual(input,
> [['1', '2', '3',
> - '"I see,"\nsaid the blind man',
> + '"I see,"\nsaid the happy man',
> 'as he picked up his\nhammer and saw'],
> ['9','8','7','6']])
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
___
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] PEP 397 (Python launcher for Windows) reference implementation
One more thing about associations - we've got pyw.exe for Python.NoConFile and py.exe for Python.file, but how do we handle Python.CompiledFile? It doesn't really make sense to have the association not handled by the launcher. Unfortunately, of course, both pyw and py compile to pyo, so we don't know which launcher to use. It is, of course, easy for either py or pyw to determine which version of python is to be used to invoke a .pyc - just not which Windows variant. BTW just as a test I implemented .pyc support in the C implementation - it works fine apart from the "python.exe or pythonw.exe?" question. Regards, Vinay Sajip ___ 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] PEP 397 (Python launcher for Windows) reference implementation
Vinay Sajip wrote: the installation of a pre-3.3 version of Python after Python 3.3 is installed with the launcher will, if the user selects "Register Extensions", hijack the laumcher's associations to that earlier Python. Then bye bye launcher I don't see how anything can be done about that. It also doesn't seem like too serious a problem -- it's no worse than what currently happens if you install an older version over a newer one, i.e. associations revert to the old version. Making the launcher a separate install at least offers a way of fixing that if it happens and isn't desired, i.e. reinstall the launcher. -- 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] PEP 397 (Python launcher for Windows) reference implementation
On 5/07/2011 11:23 AM, Greg Ewing wrote: Vinay Sajip wrote: the installation of a pre-3.3 version of Python after Python 3.3 is installed with the launcher will, if the user selects "Register Extensions", hijack the laumcher's associations to that earlier Python. Then bye bye launcher I don't see how anything can be done about that. It also doesn't seem like too serious a problem -- it's no worse than what currently happens if you install an older version over a newer one, i.e. associations revert to the old version. Making the launcher a separate install at least offers a way of fixing that if it happens and isn't desired, i.e. reinstall the launcher. Or an MSI installer may be able to offer a "repair" feature without too much pain. However, I'm a bit torn on the separate installer issue. I really think it should be installed with later Python versions even if it is made available as a separate installer for the benefit of earlier ones as it is one less step for people to get confused about - eg, in a few years when 3.3+ is the most common Python being downloaded and used, books or people helping on python-list could start referring to the launcher under the assumption it is installed, rather than avoiding mention of it simply to avoid the whole spiel about "this will only work if you have installed an optional package." IOW, it will be impossible to give unconditional advice on certain aspects of launching Python. If the launcher is such that we can unconditionally recommend its use, IMO we should just install it with Python. I'll go with the consensus though... Mark ___ 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] PEP 397 (Python launcher for Windows) reference implementation
On Tue, Jul 5, 2011 at 12:12 PM, Mark Hammond wrote: > If the launcher is such that we can unconditionally recommend its use, IMO > we should just install it with Python. I'll go with the consensus though... I've installed other WIndows apps that create multiple add/remove programs entries from a single installer. I believe people are suggesting a similar thing here (i.e. have the launcher installed automatically when installing python, but create a separate add/remove entry so uninstallation leaves it behind unless removal is explicitly requested) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] cpython: Remove mention of medical condition from the test suite.
Jim Jewett writes: > If you're going to get rid of the pun, you might as well change the > whole sentence... In fact, he should, since this is such a well-known pun that many people will consciously make the reverse substitution, and wonder WTF python-dev was thinking when they put the amended sentence in the test. Maybe somebody was *trying* to offend people who make such corrections habitually by demonstrating the kind of nonsense they occasionally produce. I've seen that target hit several times. Also, the log should say why this was done. - Remove mention of medical condition from the test suite. + Change potentially offensive language in the test suite. One could also use the somewhat euphemistic "unprofessional language". That points to why such changes are justified despite an author's right to have her mode of expression respected -- the Python project aims at professionalism, and offensive language detracts from it. ___ 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
