Python-Dev February 2011

python-dev@python.org

100 participants
109 discussions

Unbinding a name referenced by an enclosing scope - error in documentation?

by Grigory Javadyan

Hi, guys I'm not sure if python-dev is the right place to write to, but I'm really curious about this: >From the Python Language reference: > It is illegal to unbind a name referenced by an enclosing scope; the compiler will report a SyntaxError. But when I run the following code: a = 3 def x(): global a del(a) print(a) x() it works fine; and when I change the order of calls: x() print(a) I get a NameError, not a SyntaxError. Now I asked the same question on python-list and people suggested that the true meaning of that rule is: >>> def f(): ... a = 42 ... def g(): ... nonlocal a ... del a ... SyntaxError: can not delete variable 'a' referenced in nested scope Which looks weird, because the name is referenced in the _enclosed_ scope, not the _enclosing_ scope. Is there a typo in the documentation or am I missing something?

10 years, 5 months

Re: [Python-Dev] [Python-checkins] cpython: improve license

by Barry Warsaw

Notice the subject line. Can we make commit messages contain the named branch that the change applies to? The 'cpython' in the header doesn't really tell me whether I should care about this diff or not. Say the change applied to 2.6 but I only care about Python 3. It would be nice if I could just delete this message without reading the body. I guess it's possible for change notifications to encompass multiple named branches though, right? I'm not sure what to do about that, but it seems like a less common use case. -Barry On Feb 26, 2011, at 07:05 PM, benjamin.peterson wrote: >benjamin.peterson pushed 0873fb83f1e2 to cpython: > >http://hg.python.org/cpython/rev/0873fb83f1e2 >changeset: 68052:0873fb83f1e2 >tag: tip >user: Benjamin Peterson <benjamin(a)python.org> >date: Sat Feb 26 12:06:36 2011 -0600 >summary: > improve license > >files: > LICENSE

10 years, 5 months

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

by "Martin v. Löwis"

> Committing reopened it So what's the point of closing it, then? What effect does that achieve? Regards, Martin

10 years, 5 months

Re: [Python-Dev] r88589 - python/branches/py3k/Lib/test/test_logging.py

by Antoine Pitrou

On Fri, 25 Feb 2011 18:02:43 +0100 (CET) vinay.sajip <python-checkins(a)python.org> wrote: > Author: vinay.sajip > Date: Fri Feb 25 18:02:43 2011 > New Revision: 88589 > > Log: > logging: enabled test which was intermittently failing on buildbots. Looks like it fails again: ( http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds… ) ====================================================================== ERROR: test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1990, in tearDown os.unlink(self.fn) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log' ====================================================================== FAIL: test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 2053, in test_compute_rollover self.assertEqual(exp, rh.computeRollover(0.0)) AssertionError: 82800 != 18000.0 ====================================================================== FAIL: test_compute_rollover_S (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1981, in setUp BaseTest.setUp(self) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 95, in setUp raise AssertionError('Unexpected handlers: %s' % hlist) AssertionError: Unexpected handlers: [<logging.StreamHandler object at 0x0DAFC5B0>] ====================================================================== FAIL: test_compute_rollover_W0 (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1981, in setUp BaseTest.setUp(self) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 95, in setUp raise AssertionError('Unexpected handlers: %s' % hlist) AssertionError: Unexpected handlers: [<logging.StreamHandler object at 0x0DAFC5B0>]

10 years, 5 months

Why does TemporaryDirectory not wait for `__enter__`?

by cool-RR

Hello, I noticed that the `TemporaryDirectory` context manager creates the folder on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and hackarounds in `__del__`. I assume there's a good reason for this decision. What is it? Thanks, Ram.

10 years, 5 months

Re: [Python-Dev] [Python-checkins] r88601 - peps/trunk/pep-0385.txt

by Nick Coghlan

On Sat, Feb 26, 2011 at 5:12 AM, antoine.pitrou <python-checkins(a)python.org> wrote: > +In practice, most Mercurial users under Windows don't seem to have a need > +for the ``eol`` extension, though, and personal experience using a > +Linux-generated SVN checkout through a shared folder under Windows seems > +to confirm that modern tools work well without it. Feedback from the Mozilla and XEmacs folks at the time of that discussion suggested that EOL issues *were* a potential issue, and that having to revert unintentional commits of CRLF line endings was an annoyingly common problem. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

10 years, 5 months

Re: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py

by Éric Araujo

Hi, > Author: raymond.hettinger > New Revision: 88526 > Log: Add tests for the collections helper class and sync-up with py3k branch. > Modified: python/branches/release32-maint/Lib/collections.py > + def new_child(self): # like Django's Context.push() > + 'New ChainMap with a new dict followed by all previous maps.' > + return self.__class__({}, *self.maps) > + > + @property > + def parents(self): # like Django's Context.pop() > + 'New ChainMap from maps[1:].' > + return self.__class__(*self.maps[1:]) Isn’t this considered a new feature, unsuitable for 3.2? (I mean no disrespect, I just want to understand better what kind of changes can go in each type of branch.) Regards

10 years, 5 months

PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2

by Juraj Ivančić

It seems that PyEval_InitThreads() can no longer be called before Py_Initialize(). I get a fatal error in PyThreadState_GET(). This contradicts the documentation http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads Minimal repro: #include "Python.h" int main() { PyEval_InitThreads(); return 0; }

10 years, 5 months

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

by "Martin v. Löwis"

> http://hg.python.org/cpython/rev/41071f447b15 > changeset: 68041:41071f447b15 > branch: trunk > tag: tip > parent: 62750:800f6c92c3ed > user: Georg Brandl <georg(a)python.org> > date: Sat Feb 26 07:48:21 2011 +0100 > summary: > Close the "trunk" branch. What's the effect of "closing" a branch in Mercurial? I can still commit to it, hg branches still shows it (but shows 3.2 as "inactive"???). How can I find out that the branch is closed? Regards, Martin

10 years, 5 months

Re: [Python-Dev] [Python-checkins] pymigr: Update todo

by "Martin v. Löwis"

> After migration > =============== > > +* set up automatic installation of changes to ssh keys, decide upon > + account managers I would like account managers to be decided before the conversion. I personally won't be available as an account manager anymore. The new account managers are then, of course, free to establish any workflow they deem appropriate. > +* adapt build identification for Windows build process I think this should also be done before the migration. Regards, Martin

10 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev February 2011