Re: [Python-Dev] PEP 3148 ready for pronouncement
On 2010-05-21, Brian Quinlan wrote: > The PEP is here: > http://www.python.org/dev/peps/pep-3148/ [snip] Hi Brian, Could I suggest a small subtle changing in naming: replace "executor" with "executer"? I guess this suggestion is doomed though since Java uses executor:-( I'd also be tempted to rename "submit()" to "apply()" in view of Python's history. Also, maybe change "done()" to "finished()" since the function returns True if the call was cancelled (so the job can't have been "done"), as well as if the call was finished. Actually, having read further, maybe the best name would be "completed()" since that's a term used throughout. Perhaps call the "not_finished" set "pending" since presumably these are still in progress? (My understanding is that if they were cancelled or finished they'd be in the "finished" set. I'd also rename "finished" to "completed" if you have a "completed()" method.) I think FIRST_COMPLETED is misleading since it implies (to me anyway) the first one passed. How about ONE_COMPLETED; and similarly ONE_EXCEPTION? I think it would be helpful to clarify whether the timout value (which you specify as being in seconds) can meaningfully accept a float, e.g., 0.5? Anyway, it looks like it will be a really nice addition to the standard library:-) -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "C++ GUI Programming with Qt 4" - ISBN 0132354160 ___ 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 3148 ready for pronouncement
Brian Quinlan wrote:
> The PEP is here:
> http://www.python.org/dev/peps/pep-3148/
>
> I think the PEP is ready for pronouncement, and the code is pretty much
> ready for submission into py3k (I will have to make some minor changes
> in the patch like changing the copyright assignment):
> http://code.google.com/p/pythonfutures/source/browse/#svn/branches/feedback/python3/futures%3Fstate%3Dclosed
>
Your example here:
for number, is_prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
print('%d is prime: %s' % (number, is_prime))
Overwrites the 'is_prime' function with the return value of the
function. Probably better to use a different variable name.
John
=:->
___
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 3148 ready for pronouncement
Hey Mark, This really isn't the time to propose changes. The PEP has been discussed extensively on stdlib-sig and python-dev. On May 21, 2010, at 9:29 PM, Mark Summerfield wrote: On 2010-05-21, Brian Quinlan wrote: The PEP is here: http://www.python.org/dev/peps/pep-3148/ [snip] Hi Brian, Could I suggest a small subtle changing in naming: replace "executor" with "executer"? I guess this suggestion is doomed though since Java uses executor:-( I'd also be tempted to rename "submit()" to "apply()" in view of Python's history. Also, maybe change "done()" to "finished()" since the function returns True if the call was cancelled (so the job can't have been "done"), as well as if the call was finished. Actually, having read further, maybe the best name would be "completed()" since that's a term used throughout. Perhaps call the "not_finished" set "pending" since presumably these are still in progress? (My understanding is that if they were cancelled or finished they'd be in the "finished" set. I'd also rename "finished" to "completed" if you have a "completed()" method.) I think FIRST_COMPLETED is misleading since it implies (to me anyway) the first one passed. How about ONE_COMPLETED; and similarly ONE_EXCEPTION? I think it would be helpful to clarify whether the timout value (which you specify as being in seconds) can meaningfully accept a float, e.g., 0.5? I've updated the docs to clarify that float args are acceptable. Cheers, Brian Anyway, it looks like it will be a really nice addition to the standard library:-) -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "C++ GUI Programming with Qt 4" - ISBN 0132354160 ___ 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 3148 ready for pronouncement
On May 21, 2010, at 9:44 PM, John Arbash Meinel wrote:
Brian Quinlan wrote:
The PEP is here:
http://www.python.org/dev/peps/pep-3148/
I think the PEP is ready for pronouncement, and the code is pretty
much
ready for submission into py3k (I will have to make some minor
changes
in the patch like changing the copyright assignment):
http://code.google.com/p/pythonfutures/source/browse/#svn/branches/
feedback/python3/futures%3Fstate%3Dclosed
Your example here:
for number, is_prime in zip(PRIMES, executor.map(is_prime,
PRIMES)):
print('%d is prime: %s' % (number, is_prime))
Overwrites the 'is_prime' function with the return value of the
function. Probably better to use a different variable name.
Good catch. I've updated the example.
Cheers,
Brian
___
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 3148 ready for pronouncement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Quinlan wrote: > The PEP is here: > http://www.python.org/dev/peps/pep-3148/ > > I think the PEP is ready for pronouncement, and the code is pretty much > ready for submission into py3k (I will have to make some minor changes > in the patch like changing the copyright assignment): > http://code.google.com/p/pythonfutures/source/browse/#svn/branches/feedback/python3/futures%3Fstate%3Dclosed > > The tests are here and pass on W2K, Mac OS X and Linux: > http://code.google.com/p/pythonfutures/source/browse/branches/feedback/python3/test_futures.py > > The docs (which also need some minor changes) are here: > http://code.google.com/p/pythonfutures/source/browse/branches/feedback/docs/index.rst > > Cheers, > Brian > I also just noticed that your example uses: zip(PRIMES, executor.map(is_prime, PRIMES)) But your doc explicitly says: map(func, *iterables, timeout=None) Equivalent to map(func, *iterables) but executed asynchronously and possibly out-of-order. So it isn't safe to zip() against something that can return out of order. Which opens up a discussion about how these things should be used. Given that your other example uses a dict to get back to the original arguments, and this example uses zip() [incorrectly], it seems that the Futures object should have the arguments easily accessible. It certainly seems like a common use case that if things are going to be returned in arbitrary order, you'll want an easy way to distinguish which one you have. Having to write a dict map before each call can be done, but seems unoptimal. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2cugACgkQJdeBCYSNAAPWzACdE6KepgEmjwhCD1M4bSSVrI97 NIYAn1z5U3CJqZnBSn5XgQ/DyLvcKtbf =TKO7 -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
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On Thu, May 20, 2010 at 22:54, Steven D'Aprano wrote: > This is misleading, since C().method is a bound method which takes one > argument, x, not two. I find myself wishing that Python distinguished > between ArgumentError and other TypeErrors, so that the method wrapper > of bound methods could simply catch ArgumentError and subtract 1 from > each argument count. But how exactly could it distinguish between various levels of call nesting? class C: def a(self, i): return self.b(i) def b(self, j): return self.c(j) def c(self, k): return self.a() What should C.a(), C().a(), and C().a(1) each yield? Does it change if c(self, k) calls C.a(self)? -- Michael Urman ___ 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 3148 ready for pronouncement
On May 21, 2010, at 9:47 PM, John Arbash Meinel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Quinlan wrote: The PEP is here: http://www.python.org/dev/peps/pep-3148/ I think the PEP is ready for pronouncement, and the code is pretty much ready for submission into py3k (I will have to make some minor changes in the patch like changing the copyright assignment): http://code.google.com/p/pythonfutures/source/browse/#svn/branches/ feedback/python3/futures%3Fstate%3Dclosed The tests are here and pass on W2K, Mac OS X and Linux: http://code.google.com/p/pythonfutures/source/browse/branches/feedback/python3/test_futures.py The docs (which also need some minor changes) are here: http://code.google.com/p/pythonfutures/source/browse/branches/feedback/docs/index.rst Cheers, Brian I also just noticed that your example uses: zip(PRIMES, executor.map(is_prime, PRIMES)) But your doc explicitly says: map(func, *iterables, timeout=None) Equivalent to map(func, *iterables) but executed asynchronously and possibly out-of-order. So it isn't safe to zip() against something that can return out of order. The docs don't say that the return value can be out-of-order, just that execution can be out-of-order. But I agree that the phrasing is confusing so I've changed it to: Equivalent to ``map(func, *iterables)`` but *func* is executed asynchronously and several calls to *func *may be made concurrently. Which opens up a discussion about how these things should be used. Except that now isn't the time for that discussion. This PEP has discussed on-and-off for several months on both stdlib-sig and python- dev. If you think that storing the args (e.g. with the future) is a good idea then you can propose a patch after the PEP is integrated (if it is rejected then it probably isn't worth discussing ;-)). Cheers, Brian Given that your other example uses a dict to get back to the original arguments, and this example uses zip() [incorrectly], it seems that the Futures object should have the arguments easily accessible. It certainly seems like a common use case that if things are going to be returned in arbitrary order, you'll want an easy way to distinguish which one you have. Having to write a dict map before each call can be done, but seems unoptimal. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2cugACgkQJdeBCYSNAAPWzACdE6KepgEmjwhCD1M4bSSVrI97 NIYAn1z5U3CJqZnBSn5XgQ/DyLvcKtbf =TKO7 -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
Re: [Python-Dev] Documenting [C]Python's Internals
On 05/21/10 15:18, Yaniv Aknin wrote: > I would if I were qualified, but I an mot. One way to get people to help >> with details is to publish mistakes. This happens all the time on >> python-list ;-). Pre-review would be nice though. >> > > I don't mind so much the 'humiliation' of published mistakes, but since I > want this to be perceived as reference grade material, I prefer pre-review. > Yesterday my first mistake was found (ugh), I published an 'Errata Policy' > and will stick to it from now on (see the blog itself for details of the > mistake). Thankfully, I've been approached already about pre-review, we'll > see how this develops (this doesn't mean other people can't also offer > themselves, six eyeballs are better than four). How about a separate blog (or wiki) for alpha-quality articles? After an article is written, it is first posted to the alpha blog, and after some time and eyeballs, moved to the original blog. Of course with an open comment system, so people can easily suggest corrections. ___ 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] Documenting [C]Python's Internals
On 21/05/2010 13:42, Lie Ryan wrote: On 05/21/10 15:18, Yaniv Aknin wrote: I would if I were qualified, but I an mot. One way to get people to help with details is to publish mistakes. This happens all the time on python-list ;-). Pre-review would be nice though. I don't mind so much the 'humiliation' of published mistakes, but since I want this to be perceived as reference grade material, I prefer pre-review. Yesterday my first mistake was found (ugh), I published an 'Errata Policy' and will stick to it from now on (see the blog itself for details of the mistake). Thankfully, I've been approached already about pre-review, we'll see how this develops (this doesn't mean other people can't also offer themselves, six eyeballs are better than four). How about a separate blog (or wiki) for alpha-quality articles? After an article is written, it is first posted to the alpha blog, and after some time and eyeballs, moved to the original blog. Of course with an open comment system, so people can easily suggest corrections. Separate blog is confusing I think - you then duplicate your content and people are just as likely to be referred to the "alpha quality" version as the final version. Just publish and improve the articles based on feedback - I think your current approach with an established errata policy is well beyond what most people do or expect. When you have established the sort of coverage of the topic you are aiming for you can then take your blog articles, along with all feedback, and turn them into documentation. All the best, Michael ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] PEP 3148 ready for pronouncement
The description of Future.add_done_callback() does not specify whether the callbacks are done in any particular order (such as the order they were added) or not. I'm guessing they are not, but believe it should be documented either way. -- Yannick Loitière ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-05-14 - 2010-05-21) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2693 open (+46) / 17908 closed (+24) / 20601 total (+70) Open issues with patches: 1098 Average duration of open issues: 719 days. Median duration of open issues: 497 days. Open Issues Breakdown open 2672 (+46) languishing12 ( +0) pending 8 ( +0) Issues Created Or Reopened (73) ___ heapq change breaking compatibility2010-05-17 CLOSED http://bugs.python.org/issue3051reopened exarkun patch subprocess.Popen.__del__ causes AttributeError (os module == N 2010-05-14 CLOSED http://bugs.python.org/issue5099reopened haypo patch, needs review Buggy _strerror in asyncore2010-05-18 CLOSED http://bugs.python.org/issue8573reopened merwok easy multiprocessing needs option to eschew fork() under Linux 2010-05-14 http://bugs.python.org/issue8713created brandon-rhodes Delayed signals in the REPL on OpenBSD (possibly libpthread re 2010-05-14 http://bugs.python.org/issue8714created skrah Create PyUnicode_EncodeFSDefault() function2010-05-14 CLOSED http://bugs.python.org/issue8715created haypo patch test_tk fails on OS X if run from buildbot slave daemon -- cra 2010-05-14 http://bugs.python.org/issue8716created janssen patch Subprocess.py broken in trunk 2010-05-14 CLOSED http://bugs.python.org/issue8717created pakal patch subprocess: NameError: name 'WaitForSingleObject' is not def 2010-05-14 CLOSED http://bugs.python.org/issue8718created srid buildbot: segfault on FreeBSD (signal 11) 2010-05-14 http://bugs.python.org/issue8719created haypo undo findsource regression/change 2010-05-14 http://bugs.python.org/issue8720created hpk patch urlparse.urlsplit regression in 2.72010-05-15 CLOSED http://bugs.python.org/issue8721created srid Documentation for __getattr__ 2010-05-15 http://bugs.python.org/issue8722created Paul.Davis IDLE won't start import os error 2010-05-15 CLOSED http://bugs.python.org/issue8723created gromij bind_and_activate parameter is missed from directive 2010-05-15 http://bugs.python.org/issue8724created naoki Python3: use ASCII for the file system encoding on initfsencod 2010-05-15 http://bugs.python.org/issue8725created haypo patch test_capi failure 2010-05-15 CLOSED http://bugs.python.org/issue8726created pitrou test_import failure2010-05-15 CLOSED http://bugs.python.org/issue8727created pitrou 2.7 regression in httplib.py:
[Python-Dev] __package__ attribute
What are expected values for module.__package__? I see two different behaviors: importlib and standard python import. importlib processes __package__ pretty simple and clean: - for toplevel modules __package__ is empty string - for packages it's package name - for modules inside packages it's again package name Standard import follows another strategy: - it tries to setup __package__ only in case of relative import (see first 'if' in import.c:get_parent) - otherwise __package__ is untouched and None by default. For me importlib's way is better. I don't see any PEP specifying __package__ behavior. ___ 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] Adding a new C API function in 2.6
On May 21, 2010, at 01:05 AM, Martin v. Löwis wrote: Should we start thinking about releasing 2.6.6 soonish? >>> >>> By tradition, it should come out soon after 2.7 and be the last bugfix >>> (except for security patches). >> >> I guess what I mean is, should we have (at least) one more point release >> before the post-2.7 last-bug-fix-release? > >Because it's a security fix? No. This issue has been sitting in the >tracker for more than a year now, so it's not really relevant (IMO) >whether the bug fix arrives two weeks earlier. Partly that, yes. But also, 2.7 final is not scheduled until July, so we could fit one more release in I think. If there's no clamor for it, I'm also happy to just wait for 2.6.6 until after Python 2.7 is released. -Barry signature.asc Description: 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
Re: [Python-Dev] PEP 3148 ready for pronouncement
On Fri, May 21, 2010 at 8:26 AM, Brian Quinlan wrote: > Except that now isn't the time for that discussion. This PEP has discussed > on-and-off for several months on both stdlib-sig and python-dev. I think any time till the PEP is accepted is a good time to discuss changes to the API Issues with the PEP: 1) Examples as written fail on windows. Patch to fix @ http://code.google.com/p/pythonfutures/issues/detail?id=5 Issues with Implementation: 1) Globals are used for tracking running threads (but not processes) and shutdown state, but are not accessed as a globals every where they are modified so it could be inconsistent. 2) The atexit handle randomly throws an exception on exit on windows when running the tests or examples. Error in atexit._run_exitfuncs: TypeError: print_exception(): Exception expected for value, str found Issues 1 & 2 would be solved by moving thread tracking back into the executor responsible for the threads, or making a singleton that tracked threads / processes for all executors. http://code.google.com/p/pythonfutures/issues/detail?id=6 is one such implementation ___ 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] __package__ attribute
For me it's the real bug in standard python import machinery. I don't see any backward incompatibilities. There are very hard to write any import-depended code based on decision: was module imported in absolute or relative way. If it's a bug I can create issue in python bugtracker and provide a patch (for Python 3.2 and for 2.7 if later is required). On Fri, May 21, 2010 at 10:18 PM, Andrew Svetlov wrote: > What are expected values for module.__package__? > I see two different behaviors: importlib and standard python import. > importlib processes __package__ pretty simple and clean: > - for toplevel modules __package__ is empty string > - for packages it's package name > - for modules inside packages it's again package name > > Standard import follows another strategy: > - it tries to setup __package__ only in case of relative import (see > first 'if' in import.c:get_parent) > - otherwise __package__ is untouched and None by default. > > For me importlib's way is better. > I don't see any PEP specifying __package__ behavior. > ___ 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] Ask a question for a script about re.findall Modlue
Hi All,
I am working on a script to use re.findall,
But the result seems wield.
import re
p=re.compile("\S+",re.M)
pirfile="""
>DL;mm9|
>DL;petMar1|
>DL;cavPor3|
>DL;mm9|:
"""
for m in p.findall(pirfile,re.M):
print m
Results:
|
>DL;petMar1|
>DL;cavPor3|
>DL;mm9|
The first result is missing some characters, Could you explain why? Any
wrong with the script?
I tried Python2.4/2.6/2.7, the result is same.
Thank you.
Hongchao Lu
___
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] Ask a question for a script about re.findall Modlue
You shouldn't be asking questions about using Python on python-dev -- this list is for development of Python. Your problem is easily explained however: the second argument to p.findall() should be an offset, not a flag set. (You are confusing re.findall() and p.findall().) --Guido On Fri, May 21, 2010 at 4:32 PM, Lu, Hongchao (UI Health Care) < [email protected]> wrote: > Hi All, > > I am working on a script to use re.findall, > > But the result seems wield. > > > > import re > > p=re.compile("\S+",re.M) > > pirfile=""" > > >DL;mm9| > > >DL;petMar1| > > >DL;cavPor3| > > >DL;mm9|: > > """ > > for m in p.findall(pirfile,re.M): > > print m > > Results: > > | > > >DL;petMar1| > > >DL;cavPor3| > > >DL;mm9| > > The first result is missing some characters, Could you explain why? Any > wrong with the script? > > I tried Python2.4/2.6/2.7, the result is same. > > Thank you. > > Hongchao Lu > > > ___ > 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 (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
