Re: [Python-Dev] nonlocal x = value
On 12/23/2010 10:03 PM, Laurens Van Houtven wrote: On Thu, Dec 23, 2010 at 9:51 PM, Georg Brandlg.bra...@gmx.net wrote: Yes and no -- there may not be an ambiguity to the parser, but still to the human. Except if you disallow the syntax in any case, requiring people to write nonlocal x = (3, y) which is then again inconsistent with ordinary assignment statements. Right -- but (and hence the confusion) I was arguing for not mixing global/nonlocal with assignment at all, and instead having nonlocal and global only take one or more names. That would (obviously) remove any such ambiguity ;-) I would like to offer the opposing viewpoint: nonlocal x = value is a useful shortcut because nonlocal is used in closure callbacks where brevity matters. The reason nonlocal is introduced is to change the variable, so it makes sense that the two can be done in the same line of code. As for global x = value being disallowed, I have been annoyed at times with that, so that sounds like a good argument to change both. Requiring the parentheses for tuple creation sounds like a good compromise for resolving the ambiguity, consistent with similar limitations of the generator expression syntax. ___ 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] Fault handler updated, now disabled by default
On 24/12/2010 02:21, Victor Stinner wrote: Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit : this thread showed that it is not at all obvious how the feature should look like Ok, I understand. I closed #8863 (rejected) and I created a third party module on the Python cheese shop: http://pypi.python.org/pypi/faulthandler/ The module works on Linux, FreeBSD and Windows with Python 2.6 through 3.2. A third party module can evolve faster outside Python. I hope you will include it in 3.3 though; it is great functionality. I would really like to see it enabled by default as well. It seemed from the discussion that the biggest barrier to enabling it by default was possible difficulties when embedding Python (multiple interpreters, potential conflicts with application signal handling). A public C-API to disable the functionality per interpreter would be one option for this. Another possibility would be providing a C-API to enable it and have the Python interpreter application call this, so that the functionality remains off by default for embedded interpreters but on for normal uses. All the best, Michael Victor ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 22/12/2010 02:26, Terry Reedy wrote: On 12/21/2010 7:17 AM, Michael Foord wrote: My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs. Symmetrical diffs (element in first not in second, element in second not in first) solves the problem without imposing an order on the arguments. Where applicable, I prefer this as unambiguous output headings. Could you explain what you mean? All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-12-17 - 2010-12-24)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2542 ( +5)
closed 20009 (+38)
total 22551 (+43)
Open issues with patches: 1069
Issues opened (35)
==
#3243: Support iterable bodies in httplib
http://bugs.python.org/issue3243 reopened by georg.brandl
#9090: Error code 10035 calling socket.recv() on a socket with a time
http://bugs.python.org/issue9090 reopened by ehohenstein
#10731: UnicodeDecodeError in OS X tkinter when binding to MouseWheel
http://bugs.python.org/issue10731 opened by culler
#10733: plistlib rejects strings containing control characters
http://bugs.python.org/issue10733 opened by MLModel
#10734: test_ttk failure under Windows
http://bugs.python.org/issue10734 opened by pitrou
#10735: platform.architecture() gives misleading results for OS X mult
http://bugs.python.org/issue10735 opened by ned.deily
#10736: test_ttk_guionly fails on OS X using ActiveState Tcl 8.5.9 (Co
http://bugs.python.org/issue10736 opened by ned.deily
#10737: test_concurrent_futures failure on Windows
http://bugs.python.org/issue10737 opened by pitrou
#10738: webbrowser.py bug with Opera on Linux
http://bugs.python.org/issue10738 opened by NE1
#10739: Subprocess behavior on Windows
http://bugs.python.org/issue10739 opened by rosslagerwall
#10740: sqlite3 module should allow DDL statements in transactions
http://bugs.python.org/issue10740 opened by scott.urban
#10741: PyGILState_GetThisThreadState() lacks a doc entry
http://bugs.python.org/issue10741 opened by pitrou
#10742: memoryview.readonly attribute is not documented
http://bugs.python.org/issue10742 opened by flashk
#10744: ctypes arrays have incorrect buffer information (PEP-3118)
http://bugs.python.org/issue10744 opened by pv
#10745: setup.py install --user option undocumented
http://bugs.python.org/issue10745 opened by gotgenes
#10746: ctypes c_long c_bool have incorrect PEP-3118 type codes
http://bugs.python.org/issue10746 opened by pv
#10747: Include version info in Windows shortcuts
http://bugs.python.org/issue10747 opened by ncoghlan
#10751: WSGIREF - REMOTE_USER and REMOTE-USER collision
http://bugs.python.org/issue10751 opened by Alex.Raitz
#10752: build_ssl.py is relying on unreliable behaviour of os.popen
http://bugs.python.org/issue10752 opened by srid
#10753: request_uri method of wsgiref module does not support RFC1808
http://bugs.python.org/issue10753 opened by Timothy.Gates
#10755: Add posix.fdlistdir
http://bugs.python.org/issue10755 opened by rosslagerwall
#10756: Error in atexit._run_exitfuncs [...] Exception expected for v
http://bugs.python.org/issue10756 opened by kaizhu
#10757: zipfile.write, arcname should be bytestring
http://bugs.python.org/issue10757 opened by connexion2000
#10758: posix_access swallows all errors
http://bugs.python.org/issue10758 opened by georg.brandl
#10759: HTMLParser.unescape() fails on HTML entities with incorrect sy
http://bugs.python.org/issue10759 opened by Martin.Potthast
#10760: tarfile doesn't handle sysfs well
http://bugs.python.org/issue10760 opened by Yoni.Tsafir
#10761: tarfile.extractall fails to overwrite symlinks
http://bugs.python.org/issue10761 opened by srid
#10762: strftime('%f') segfault
http://bugs.python.org/issue10762 opened by dleonard0
#10763: subprocess.communicate() doesn't close pipes on Windows
http://bugs.python.org/issue10763 opened by haypo
#10764: sysconfig and alternative implementations
http://bugs.python.org/issue10764 opened by michael.foord
#10765: Build regression from automation changes on windows
http://bugs.python.org/issue10765 opened by gz
#10766: optparse uses %s in gettext calls
http://bugs.python.org/issue10766 opened by eric.araujo
#10767: Lib/test/crashers/README is out of date
http://bugs.python.org/issue10767 opened by belopolsky
#10768: Bug in scrolledtext
http://bugs.python.org/issue10768 opened by quentel
#10769: ast: provide more useful range information
http://bugs.python.org/issue10769 opened by scummos
Most recent 15 issues with no replies (15)
==
#10769: ast: provide more useful range information
http://bugs.python.org/issue10769
#10767: Lib/test/crashers/README is out of date
http://bugs.python.org/issue10767
#10766: optparse uses %s in gettext calls
http://bugs.python.org/issue10766
#10764: sysconfig and alternative implementations
http://bugs.python.org/issue10764
#10763: subprocess.communicate() doesn't close pipes on Windows
http://bugs.python.org/issue10763
#10761: tarfile.extractall fails to overwrite symlinks
http://bugs.python.org/issue10761
#10760: tarfile doesn't handle sysfs well
http://bugs.python.org/issue10760
#10756: Error in atexit._run_exitfuncs [...] Exception expected for v
http://bugs.python.org/issue10756
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/24/2010 11:09 AM, Michael Foord wrote: On 22/12/2010 02:26, Terry Reedy wrote: On 12/21/2010 7:17 AM, Michael Foord wrote: My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs. Symmetrical diffs (element in first not in second, element in second not in first) solves the problem without imposing an order on the arguments. Where applicable, I prefer this as unambiguous output headings. Could you explain what you mean? I was referring back to an output example symmetric diff that was clipped somewhere along the way: In x not in y: ... In y not in x: ... rather than just using -,+ prefixes which are not necessarily self-explanatory. 'Not applicable' would refer to output from difflib which necessarily is ordered. -- Terry Jan Reedy ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote: On 12/24/2010 11:09 AM, Michael Foord wrote: On 22/12/2010 02:26, Terry Reedy wrote: On 12/21/2010 7:17 AM, Michael Foord wrote: My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs. Symmetrical diffs (element in first not in second, element in second not in first) solves the problem without imposing an order on the arguments. Where applicable, I prefer this as unambiguous output headings. Could you explain what you mean? I was referring back to an output example symmetric diff that was clipped somewhere along the way: In x not in y: ... In y not in x: ... rather than just using -,+ prefixes which are not necessarily self-explanatory. 'Not applicable' would refer to output from difflib which necessarily is ordered. FWIW, I think + and - prefixes are much better for diffs that some made-up verbiage. People are used to seeing diffs with + and -. Anything else will be so contrived that it's net effect will be to make the output confusing and hard to interpret. If you want, add two lines of explanation before the diff: + means in x, not in y - means in y, not it x The notion of making symmetric can easily get carried too far, which a corresponding loss of useability. You get 95% of the benefit from two small changes: * Change the parameter names from actual and expected to first and second * Change the words unexpected and missing to in first, not in second and in second, not in first. We have a strong history in using +/- and shouldn't throw away its brevity and clarity. Raymond ___ 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] Fault handler updated, now disabled by default
Michael Foord writes: It seemed from the discussion that the biggest barrier to enabling it by default was possible difficulties when embedding Python (multiple interpreters, potential conflicts with application signal handling). A public C-API to disable the functionality per interpreter would be one option for this. That's not really good enough. The point of installing a handler like this is to catch them squirmers. All you have to do is override some incautious developer's own squirmer-trap handler once, and Python has made an Enemy-For-Life. (This happened to XEmacs with esound. I immediately removed esound and anything that depends on it from my workstation. ;-) YMMV and you may think that that is not so important; my point is that the proposal to provide a way to disable does not at all address the objection. Another possibility would be providing a C-API to enable it and have the Python interpreter application call this, so that the functionality remains off by default for embedded interpreters but on for normal uses. I think this is heading in the right direction. Note: My own experience with such handlers has been positive, but it does not involve embedding interpreters in either direction, so not really helpful in addressing this objection. Precisely *because* my own experience has been positive, I worry about interfering with some third party's handler. ___ 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] Compiling CPython to javascript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Interesting development. http://syntensity.com/static/python.html http://syntensity.blogspot.com/ - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTRV1s5lgi5GaxT1NAQLO1gQAjwjfyVHmQOgNg9cBD/lDZFoHJhPSbfaY KGnXVOVbXoAo6+o7Ne7mXXWamD38VK9et7dWckyWbqubHk1IGLuP9eCncKKjuX4j UTFMG26i4p24oQ6AMyUs2wuC7ockZ4PK8r7vcPs3YxSRR5rx81ojaH6SFQ2qJJGc kRTtNe+iExc= =UPG8 -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
