Re: [Python-Dev] nonlocal x = value
Hrvoje Niksic, 24.12.2010 09:45: On 12/23/2010 10:03 PM, Laurens Van Houtven wrote: On Thu, Dec 23, 2010 at 9:51 PM, Georg Brandl 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. I doubt that it really matters so much that one line more kills readability. It's still a relatively rare use case after all. 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. But still, this is just a special case. If the variable is changed more than once, you'd end up with one assignment with nonlocal and one without. This just adds to the growing list of code inconsistencies presented in this thread. 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. Why introduce such a pitfall for coders here? "Require" doesn't mean the parser can enforce it. If it's not there, it just means something else, so it's up to the coder to get it right. The exact same kind of situation that was fixed for the except syntax in Python 3. Stefan ___ 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] r87478 - python/branches/py3k/Misc/maintainers.rst
Eh, no. That is a different user. Alan didn't have Developer tracker privileges yet though, so I fixed that. Please revert. Georg Am 24.12.2010 22:59, schrieb terry.reedy: > Author: terry.reedy > Date: Fri Dec 24 22:59:03 2010 > New Revision: 87478 > > Log: > Match current tracker name, though I do not know if still active. > > > Modified: >python/branches/py3k/Misc/maintainers.rst > > Modified: python/branches/py3k/Misc/maintainers.rst > == > --- python/branches/py3k/Misc/maintainers.rst (original) > +++ python/branches/py3k/Misc/maintainers.rst Fri Dec 24 22:59:03 2010 > @@ -247,7 +247,7 @@ > xml.sax.saxutils > xml.sax.xmlreader > xmlrpc loewis > -zipfile alanmcintyre > +zipfile aimacintyre > zipimport > zlib > == === ___ 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] Fault handler updated, now disabled by default
Le vendredi 24 décembre 2010 à 12:59 +, Michael Foord a écrit : > I hope you will include it in 3.3 though; it is great functionality. I don't know, Python 3.3 is not planned yet. Anyway, faulthandler is already available and you can use it on Python 2.5 through 3.2. > I would really like to see it enabled by default as well. For different reasons, it is not a good idea to enable it by default (see the recent discussion on this list). > It seemed from the discussion that the biggest barrier to enabling it by > default was possible difficulties when ... Yes, that's why it was disabled by default in the latest version of my patch. > (multiple interpreters, I think that my fault handler works with multiple interpreters. > potential conflicts with application signal handling) Very few programs have an handler for SIGSEGV, SIGFPE, SIGILL or SIGBUS signals (but yes, there are such programs/libraries like RPy or XEmacs). > 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. I think that it's better to disable it by default, and only enabled by the user or by the developer of a specific application. -- Anyway, you don't have to wait Python 3.3 (or Python 3.2): you can already use faulthandler ;-) I created Windows installer for Python 2.6, 2.7 and 3.1 (I will do it for 2.5 too in the next faulthandler version, faulthandler 1.0 tests don't work with Python 2.5). faulthandler is a module: enable the handler is simple as "import faulthandler". Said differently, it's also disabled by default, and only enabled by the application developer. It's harder to enable it for the user, the site module should maybe be patched to load the module if an environment variable exist or a command line argument. 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] Fault handler updated, now disabled by default
> faulthandler is a module: enable the handler is simple as "import > faulthandler". That sounds like a source of unwanted behavior (aka problems) if the handler is enabled by “pydoc faulthandler” or by a pkgutil walk. You may want to consider using a function to enable the functionality (and add one to disable it). Regards ___ 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
