Python-Dev March 2012

python-dev@python.org

138 participants
141 discussions

by Matěj Cepl

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

9 years, 6 months

Issue 14417: consequences of new dict runtime error

by R. David Murray

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

9 years, 6 months

Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?

by Victor Stinner

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

9 years, 6 months

datetime module and pytz with dateutil

by Andrew Svetlov

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

9 years, 6 months

Re: [Python-Dev] Issue 14417: consequences of new dict runtime error

by Etienne Robillard

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

9 years, 6 months

Using Cython for developing a module to be used from postgreSQL/pl/python

by Hannu Krosing

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/

9 years, 6 months

Issue13210 : Support Visual Studio 2010

by Kristján Valur Jónsson

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

9 years, 6 months

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

by Andrew Svetlov

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

9 years, 6 months

Issue #14310: Socket duplication for windows

by Kristján Valur Jónsson

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

9 years, 6 months

Re: [Python-Dev] [Python-checkins] cpython: Issue #14065: Added cyclic GC support to ET.Element

by Benjamin Peterson

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

9 years, 6 months

Jump to page:

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 March 2012