Mailman 3 March 2012 - Python-Dev

.{git,bzr}ignore in cpython HG repo
by Matěj Cepl 04 Apr '12

04 Apr '12

Why does HG cpython repo contains .{bzr,git}ignore at all? IMHO, all .*ignore files should be strictly repository dependent and they should not be mixed together. It is even worse, that (understandingly) .{bzr,git}ignore are apparently poorly maintained, so in order to get an equivalent of .hgignore in .gitignore, one has to apply the attached patch. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC We understand our competition isn't with Caldera or SuSE--our competition is with Microsoft. -- Bob Young of Red Hat http://www.linuxjournal.com/article/3553

16 21

Issue 14417: consequences of new dict runtime error
by R. David Murray 03 Apr '12

03 Apr '12

Some of us have expressed uneasiness about the consequences of dict raising an error on lookup if the dict has been modified, the fix Victor made to solve one of the crashers. I don't know if I speak for the others, but (assuming that I understand the change correctly) my concern is that there is probably a significant amount of threading code out there that assumes that dict *lookup* is a thread-safe operation. Much of that code will, if moved to Python 3.3, now be subject to random runtime errors for which it will not be prepared. Further, code which appears safe can suddenly become unsafe if a refactoring of the code causes an object to be stored in the dictionary that has a Python equality method. Would it be possible to modify the fix so that the lookup is retried a non-trivial but finite number of times, so that normal code will work and only pathological code will break? I know that I really don't want to think about having to audit the (significantly threaded) application I'm currently working on to make sure it is "3.3 safe". Dict lookup operations are *common*, and we've never had to think about whether or not they were thread-safe before (unless there were inter-thread synchronization issues involved, of course). Nor am I sure the locking dict type suggested by Jim on the issue would help, since a number of the dicts we are using are produced by library code. So we'd have to wait for those libraries to be ported to 3.3.... --David

8 26

Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
by Victor Stinner 03 Apr '12

03 Apr '12

Hi, Windows provides two main monotonic clocks: QueryPerformanceCounter() and GetTickCount(). QueryPerformanceCounter() has a good accuracy (0.3 ns - 5 ns) but has various issues and is know to not have a steady rate. GetTickCount() has a worse accuracy (1 ms - 15 ms) but is more stable and behave better on system suspend/resume. The glib library prefers GetTickCount() over QueryPerformanceCounter() for its g_get_monotonic_time() because "The QPC timer has too many issues to be used as is." Ihttp://mail.gnome.org/archives/commits-list/2011-November/msg04589.html The Qt library tries QueryPerformanceCounter() but may fallback to GetTickCount() if it is not available. python-monotonic-time only uses GetTickCount() or GetTickCount64(). It is important to decide which clock is used for the Python time.monotonic() because it may change the design of the PEP 418. If we use GetTickCount() for time.monotonic(), we should use QueryPerformanceCounter() for time.highres(). But in this case, it means that time.highres() is not a simple "try monotonic or falls back to system time", but may use a different clock with an higher resolution. So we might add a third function for the "try monotonic or falls back to system time" requirement. Python implements time.clock() using QueryPerformanceCounter() on Windows. Victor

11 34

datetime module and pytz with dateutil
by Andrew Svetlov 01 Apr '12

01 Apr '12

I figured out what pytz and dateutil are not mentioned in python docs for datetime module. It's clean why these libs is not a part of Python Libraries — but that's not clean for Docs. >From my perspective at least pytz (as py3k compatible) should to be mentioned as the library which contains timezone info, supported carefully and recommended to use with datetime standard module, -- Thanks, Andrew Svetlov

8 13

Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
by Etienne Robillard 01 Apr '12

01 Apr '12

On 03/30/2012 03:02 PM, Guido van Rossum wrote: > Hey Etienne, I am honestly trying to understand your contribution but > you seem to have started a discussion about free speech. Trust me that > we don't mind your contributions, we're just trying to understand what > you're saying, and the free speech discussion isn't helping with that. I agree. > So if you have a comment on the dict mutation problem, please say so. OK. > If you need help understanding the problem, python-dev is not the > place to ask questions; you could ask on the bug, or on the > core-mentorship list as Nick suggested. But please stop bringing up > free speech, that's not an issue. Guido, thanks for the wisdom and clarity of your reasoning. I really appreciate a positive attitude towards questioning not so obvious problems. So far I was only attempting to verify whether this is related to PEP-416 or not. If this is indeed related PEP 416, then I must obviously attest that I must still understand why a immutable dict would prevent this bug or not... Either ways, I fail to see where this is OT or should be discussed on a more obscur forum than python-dev. :-) Kind regards, Etienne

4 7

Using Cython for developing a module to be used from postgreSQL/pl/python
by Hannu Krosing 31 Mar '12

31 Mar '12

Hi Has anyone used Cython for developing a module to be used from postgreSQL/pl/python. Something that calls back to PostgreSQL internals. ------- Hannu Krosing PostgreSQL Unlimited Scalability and Performance Consultant 2ndQuadrant Nordic PG Admin Book: http://www.2ndQuadrant.com/books/

4 5

Issue13210 : Support Visual Studio 2010
by Kristján Valur Jónsson 31 Mar '12

31 Mar '12

Hi, Does anyone object if I submit my patches sxs.patch and errnomodule.patch? These allow python to work correctly when built with vs2010. There is also the PCBuild10.patch, but that can wait. I'm sure a number of people are regularly building python using vs2010 using their own modified solutions, but having the sources in a constant state of patching is a nuiscance so I think we ought to at least make the source code work with it, regardless of having a proper solution for it. K

3 2

Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #14409: IDLE doesn't not execute commands from shell with default
by Andrew Svetlov 31 Mar '12

31 Mar '12

Updated NEWS as Terry Reedy recommended. Thank you, Terry. On Sat, Mar 31, 2012 at 12:59 AM, Terry Reedy <tjreedy(a)udel.edu> wrote: > On 3/30/2012 2:31 PM, Andrew Svetlov wrote: >> >> Thank you for mentoring. >> >> I will fix NEWS if you help me with better text. > > > I believe a succint message would be > > Issue 14409: IDLE now properly executes commands in the Shell window when it > cannot read the normal config files on startup and has to use the built-in > default key bindings. There was previously a bug in one of the defaults. > > >> The bug fixed is that commit is: >> IDLE has 3 configs: user, system default and hardcoded in python code. >> Last one had bad binding for<Return> key. >> Usually this config is never used: user or system ones overrides former. >> But if IDLE cannot open config files by some reason it switches to >> hardcoded configs and user got broken IDLE. >> >> Can anybody guess me short and descriptive message describing what fix >> well? >> >> On Fri, Mar 30, 2012 at 6:12 AM, Nick Coghlan<ncoghlan(a)gmail.com> wrote: >>> >>> On Fri, Mar 30, 2012 at 2:01 AM, andrew.svetlov >>> <python-checkins(a)python.org> wrote: >>>> >>>> +- Issue #14409: IDLE doesn't not execute commands from shell, >>>> + error with default keybinding for Return. (Patch by Roger Serwy) >>> >>> >>> The double negative here makes this impossible to understand. Could we >>> please get an updated NEWS entry that explains what actually changed >>> in IDLE to fix this? >>> >>> Perhaps something like "IDLE now always sets the default keybind for >>> Return correctly, ensuring commands can be executed in the IDLE shell >>> window"? (assuming that's what happened). >>> >>> This is important, folks: NEWS entries need to be comprehensible for >>> people that *haven't* read the associated tracker issue. This means >>> that issue titles (which generally describe a problem someone was >>> having) are often inappropriate as NEWS items. NEWS items should be >>> short descriptions that clearly describe *what changed*, perhaps with >>> some additional information to explain a bit about why the change was >>> made. > > > -- > Terry Jan Reedy > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins -- Thanks, Andrew Svetlov

2 1

Issue #14310: Socket duplication for windows
by Kristján Valur Jónsson 31 Mar '12

31 Mar '12

Hi there. Antoine Pitroue requested that this topic (http://bugs.python.org/issue14310) be discussed by python-dev before moving further. I'm adding a windows-only api to "share" sockets between processes to _socket in the canonical way. Multiprocessing already has code for this (using unsupported methods) but a subsequent change could then simplify that. thanks, Kristján

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #14065: Added cyclic GC support to ET.Element
by Benjamin Peterson 31 Mar '12

31 Mar '12

2012/3/30 eli.bendersky <python-checkins(a)python.org>: > http://hg.python.org/cpython/rev/0ca32013d77e > changeset: 75997:0ca32013d77e > parent: 75995:cf2e74e0b7d4 > user: Eli Bendersky <eliben(a)gmail.com> > date: Fri Mar 30 16:38:33 2012 +0300 > summary: > Issue #14065: Added cyclic GC support to ET.Element > > files: > Lib/test/test_xml_etree.py | 27 ++++++++++- > Modules/_elementtree.c | 63 +++++++++++++++++++------ > 2 files changed, 74 insertions(+), 16 deletions(-) > > > diff --git a/Lib/test/test_xml_etree.py b/Lib/test/test_xml_etree.py > --- a/Lib/test/test_xml_etree.py > +++ b/Lib/test/test_xml_etree.py > @@ -14,9 +14,10 @@ > # Don't re-import "xml.etree.ElementTree" module in the docstring, > # except if the test is specific to the Python implementation. > > -import sys > +import gc > import html > import io > +import sys > import unittest > > from test import support > @@ -1846,6 +1847,30 @@ > self.assertRaises(TypeError, e.extend, [ET.Element('bar'), 'foo']) > self.assertRaises(TypeError, e.insert, 0, 'foo') > > + def test_cyclic_gc(self): > + class ShowGC: > + def __init__(self, flaglist): > + self.flaglist = flaglist > + def __del__(self): > + self.flaglist.append(1) I think a nicer way to check for cyclic collection is to take a weakref to an object, call the GC, then check to make sure the weakref is broken. > + > + # Test the shortest cycle: lst->element->lst > + fl = [] > + lst = [ShowGC(fl)] > + lst.append(ET.Element('joe', attr=lst)) > + del lst > + gc.collect() support.gc_collect() is preferable > + self.assertEqual(fl, [1]) > + > + # A longer cycle: lst->e->e2->lst > + fl = [] > + e = ET.Element('joe') > + lst = [ShowGC(fl), e] > + e2 = ET.SubElement(e, 'foo', attr=lst) > + del lst, e, e2 > + gc.collect() > + self.assertEqual(fl, [1]) -- Regards, Benjamin

2 1