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....
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."
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.
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,
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.
> So if you have a comment on the dict mutation problem, please say so.
> 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. :-)
Has anyone used Cython for developing a module to be used from
Something that calls back to PostgreSQL internals.
PostgreSQL Unlimited Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/
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.
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
>> 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
> Terry Jan Reedy
> Python-checkins mailing list
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.
On Fri, Mar 30, 2012 at 2:01 AM, andrew.svetlov
> +- 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
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia