Re: [Python-Dev] PEP 418: Add monotonic clock
On Sat, Mar 31, 2012 at 02:26, Steven D'Aprano st...@pearwood.info wrote: Guido van Rossum wrote: If all else fails, I'd go with turnip. I can't tell if you are being serious or not. For the record, turnip in this sense is archaic slang for a thick pocket watch. If I understand this correctly, the most common use for this function is when to time things. It will give you the best source available for timers, but it doesn't guarantee that it is steady or monotonic or high resolution or anything. It is also not the time, as it's not reliable as a wall-clock. So, how about time.timer()? //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On Fri, Mar 30, 2012 at 12:38, Serhiy Storchaka storch...@gmail.com wrote: I don't understand why Python may not include the pytz. The Olson tz database is not part of pytz. Yes it is. Python can depend on a system tz database That works on Unix, but not on Windows, where there is no Olsen database. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: Add monotonic clock
On Sat, Mar 31, 2012 at 8:27 AM, Lennart Regebro rege...@gmail.com wrote: So, how about time.timer()? That seems like a bad idea; it would be too easy to confuse with (or misspell as) time.time(). Out of the big synonym list Guido posted, I rather like time.stopwatch() - it makes it more explicit that the purpose of the function is to measure intervals, rather identifying absolute points in time. Cheers, Nadeem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On 31 Mar 2012, at 07:32, Lennart Regebro wrote: On Fri, Mar 30, 2012 at 12:38, Serhiy Storchaka storch...@gmail.com wrote: I don't understand why Python may not include the pytz. The Olson tz database is not part of pytz. Yes it is. Python can depend on a system tz database That works on Unix, but not on Windows, where there is no Olsen database. *However*, doesn't Windows have its own system database? The problem is that in order to not include the olsen database, pytz (which would be a very useful addition to the standard library) would need to be modified to use the system database on Windows. This is my (potentially flawed) understanding, anyway. Michael //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #14409: IDLE doesn't not execute commands from shell with default
Updated NEWS as Terry Reedy recommended. Thank you, Terry. On Sat, Mar 31, 2012 at 12:59 AM, Terry Reedy tjre...@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 forReturn 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 Coghlanncogh...@gmail.com wrote: On Fri, Mar 30, 2012 at 2:01 AM, andrew.svetlov python-check...@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-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
The frozendict builtin type was rejected, but we are going to add types.MappingProxyType: see issue #14386. types.MappingProxyType(mydict.copy()) is very close to the frozendict builtin type. Victor Thanks, Victor. :) Will this mean the new dict subclass for CPython will not expose dictproxy to favorize a new types.MappingProxyType type to emulate immutable-like types ? What could be then consequences for code still expecting a non-mutable dict() type ? Therefore I guess this ticket provides more than just speculating points to reconsider such aliased types in cpython. I also found this article quite useful: http://www.cs.toronto.edu/~tijmen/programming/immutableDictionaries.html Yet I might miss how this new dict type could potentially induce a RuntimeError unless in python 3.3 a new dict proxy alias is introduced to perform invariant operations in non thread-safe code. Regards, Etienne ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On Sat, Mar 31, 2012 at 12:28, Michael Foord fuzzy...@voidspace.org.uk wrote: *However*, doesn't Windows have its own system database? Yeah, but it sucks. The problem is that in order to not include the olsen database, pytz would need to be modified to use the system database on Windows. Quite a lot too, I'd guess since the databases are completely different in pretty much every way, most importantly in the way that they are using different (and insane) names for the timezones. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
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/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
Hannu Krosing, 31.03.2012 14:22: Has anyone used Cython for developing a module to be used from postgreSQL/pl/python. Something that calls back to PostgreSQL internals. Note that this is the CPython core developers mailing list, for which your question is off-topic. Please ask on the cython-users mailing list (see http://cython.org). Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
On Sat, 2012-03-31 at 14:41 +0200, Stefan Behnel wrote: Hannu Krosing, 31.03.2012 14:22: Has anyone used Cython for developing a module to be used from postgreSQL/pl/python. Something that calls back to PostgreSQL internals. Note that this is the CPython core developers mailing list, for which your question is off-topic. Please ask on the cython-users mailing list (see http://cython.org). Thanks for the pointer ! Can you recommend a similar place for asking the same queston about ctypes ? That is using ctypes for calling back to outer c application which embeds the python interpreter. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/hannu%40krosing.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue13210 : Support Visual Studio 2010
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue #14310: Socket duplication for windows
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
Hannu Krosing ha...@krosing.net writes: Has anyone used Cython for developing a module to be used from postgreSQL/pl/python. Something that calls back to PostgreSQL internals. Are you aware that PostgreSQL has long provided Python as a language for writing stored procedures in the database? URL:http://www.postgresql.org/docs/current/static/plpython.html Does that meet your needs? -- \ “You've got to think about big things while you're doing small | `\ things, so that all the small things go in the right | _o__) direction.” —Alvin Toffler | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
On Sun, 2012-04-01 at 00:44 +1100, Ben Finney wrote:
Hannu Krosing ha...@krosing.net writes:
Has anyone used Cython for developing a module to be used from
postgreSQL/pl/python.
Something that calls back to PostgreSQL internals.
Are you aware that PostgreSQL has long provided Python as a language for
writing stored procedures in the database?
URL:http://www.postgresql.org/docs/current/static/plpython.html
Does that meet your needs?
Sure, I have even contributed code to it ;)
But what i want is some way to call _back_ into PostgreSQL to use its
internal functions from a module imported from pl/python.
I tried ctypes module and got a segfault when i used the following
create or replace function callback_to_postgres(rn_text text)
returns text
language plpythonu
as
$$
from ctypes import *
import struct
pg = cdll.LoadLibrary('/usr/lib/postgresql/9.1/bin/postmaster')
pg.pq_flush()
return rn_text
$$;
select send_raw_notice('do you see me?');
CRASHES HERE
I determined that the call to pg.pq_flush() was the one crashing the
backend, so I assume that cdll.LoadLibrary did not get the already
running backend, but loaded another copy of it as library.
Now I'm looking for a simplest way to do some C-wrapping. I have used
Cyuthon for wrapping simple library calls and I really don'r think there
would be hard problems doing this inside the postgreSQL extension build
framework.
I was just hoping that someboduy had already taken care of all the
nitty-gritty detaiuls of setting this up
---
Hannu Krosing
PostgreSQL Unlimited Scalability and Performance Consultant
2ndQuadrant Nordic
PG Admin Book: http://www.2ndQuadrant.com/books/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue13210 : Support Visual Studio 2010
2012/3/31 Kristján Valur Jónsson krist...@ccpgames.com: 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. Go ahead. As listed on the issue, there is a repo where building from VS2010 works but the port is not complete as not all tests are passing. I will complete it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
On Sat, 31 Mar 2012 07:43:28 -0400, Etienne Robillard animelo...@gmail.com wrote: Yet I might miss how this new dict type could potentially induce a RuntimeError unless in python 3.3 a new dict proxy alias is introduced to perform invariant operations in non thread-safe code. Etienne, again: issue 14417 has *nothing* to do with immutable dicts. Please carefully read over issue 14205 in order to understand what we are talking about so that you can contribute to the discussion. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
On Thu, Mar 29, 2012 at 1:48 PM, R. David Murray rdmur...@bitdance.com wrote: On Thu, 29 Mar 2012 16:31:03 -0400, R. David Murray rdmur...@bitdance.com wrote: On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum gu...@python.org wrote: My original assessment was that this only affects dicts whose keys have a user-implemented __hash__ or __eq__ implementation, and that the number of apps that use this *and* assume the threadsafe property would be pretty small. This is just intuition, I don't have hard facts. But I do want to stress that not all dict lookups automatically become thread-unsafe, only those that need to run user code as part of the key lookup. You are probably correct, but the thing is that one still has to do the code audit to be sure...and then make sure that no one later introduces such an object type as a dict key. I just did a quick grep on our project. We are only defining __eq__ and __hash__ a couple places, but both are objects that could easily get used as dict keys (there is a good chance that's *why* those methods are defined) accessed by more than one thread. I haven't done the audit to find out :) Of course, that doesn't mean they're likely to be used as keys in a dict that is read and written concurrently by multiple threads. The libraries we depend on have many more definitions of __eq__ and __hash__, and we'd have to check them too. (Including SQLAlchemy, and I wouldn't want that job.) So our intuition that this is not common may be wrong. But how often does one share a dictionary between threads with the understanding that multiple threads can read and write it? Here's a different puzzle. Has anyone written a demo yet that provokes this RuntimeError, without cheating? (Cheating would be to mutate the dict from *inside* the __eq__ or __hash__ method.) If you're serious about revisiting this, I'd like to see at least one example of a program that is broken by the change. Otherwise I think the status quo in the 3.3 repo should prevail -- I don't want to be stymied by superstition. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #14409: IDLE doesn't not execute commands from shell with default
On Sat, Mar 31, 2012 at 9:21 PM, Andrew Svetlov andrew.svet...@gmail.com wrote: Updated NEWS as Terry Reedy recommended. Thank you, Terry. Thanks to you both :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum gu...@python.org wrote: Here's a different puzzle. Has anyone written a demo yet that provokes this RuntimeError, without cheating? (Cheating would be to mutate the dict from *inside* the __eq__ or __hash__ method.) If you're serious about revisiting this, I'd like to see at least one example of a program that is broken by the change. Otherwise I think the status quo in the 3.3 repo should prevail -- I don't want to be stymied by superstition. I attached an attempt to *deliberately* break the new behaviour to the tracker issue. It isn't actually breaking for me, so I'd like other folks to look at it to see if I missed something in my implementation, of if it's just genuinely that hard to induce the necessary bad timing of a preemptive thread switch. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue13210 : Support Visual Studio 2010
Does anyone object if I submit my patches sxs.patch and errnomodule.patch? These allow python to work correctly when built with vs2010. Please see my review: allow to work correctly is not a good explanation of what it does, and why it does that. As it is highly counter-intuitive, it needs at least justification. I'm trying to investigate whether it is actually correct (and that it works for CCP is not sufficient proof that it is correct). Also, please clarify what branches you would apply this to. 3.3 is certainly fine; for any other branches, I'd like to point out that this is not a bug fix. There is also the PCBuild10.patch, but that can wait. Indeed, it shouldn't be added at all. Instead, the PCbuild tree should become a VS2010 (or VS2012) tree ultimately. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
Can you recommend a similar place for asking the same queston about ctypes ? That is using ctypes for calling back to outer c application which embeds the python interpreter. ISTM that Postgres lists should be the best place for this kind of question. Alternatively, try python-list or db-sig. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum gu...@python.org wrote: Here's a different puzzle. Has anyone written a demo yet that provokes this RuntimeError, without cheating? (Cheating would be to mutate the dict from *inside* the __eq__ or __hash__ method.) If you're serious about revisiting this, I'd like to see at least one example of a program that is broken by the change. Otherwise I think the status quo in the 3.3 repo should prevail -- I don't want to be stymied by superstition. I attached an attempt to *deliberately* break the new behaviour to the tracker issue. It isn't actually breaking for me, so I'd like other folks to look at it to see if I missed something in my implementation, of if it's just genuinely that hard to induce the necessary bad timing of a preemptive thread switch. Thanks, Nick. It looks reasonable to me, but I've only given it a quick look so far (I'll try to think about it more deeply later today). If it is indeed hard to provoke, then I'm fine with leaving the RuntimeError as a signal that the application needs to add some locking. My concern was that we'd have working production code that would start breaking. If it takes a *lot* of threads or a *lot* of mutation to trigger it, then it is going to be a lot less likely to happen anyway, since such programs are going to be much more careful about locking anyway. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On 3/31/2012 6:28 AM, Michael Foord wrote: On 31 Mar 2012, at 07:32, Lennart Regebro wrote: On Fri, Mar 30, 2012 at 12:38, Serhiy Storchakastorch...@gmail.com wrote: I don't understand why Python may not include the pytz. The Olson tz database is not part of pytz. Yes it is. Python can depend on a system tz database That works on Unix, but not on Windows, where there is no Olsen database. *However*, doesn't Windows have its own system database? The problem is that in order to not include the olsen database, pytz (which would be a very useful addition to the standard library) would need to be modified to use the system database on Windows. This is my (potentially flawed) understanding, anyway. The Windows installer, by default, installs tcl/tk while Python on other systems uses the system install. Why can't we do the same for the Olson database? As for updates: The correct behavior for timezone functions is to use the most recent definitions of those functions. The date is an input parameter for those functions. Projection of correct behavior for today's date into the future is provisional and subject to correction. This is especially true of anything involving Daylight Stupid Time. (As you can tell, I would have it go away.) Testing the specific output of such functions with future dates is broken. So I think we should define correct behavior of pytz as use with the latest Olson database. Use with an older version would then be a 'bug' subject to being fixed. On Windows, we could update as needed with every bugfix release. (And give instructions for user update.) On other systems, users can do whatever is appropriate. Or perhaps we could add an 'update tz database' function to the module. Similary, our unicode implementation is defined as using the unicode database as of a few weeks before each feature release. Updates for bugfix releases are not done because changes to that database are a few additions each time rather than edits. -- As a side note: I think the same trick of defining correct behavior dynamically rather that statically could be applied to other modules, such mimetypes and internet protocol modules. This seems to be part of the intent of the idea of having stdlib feature releases every 6 months or so. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On Sat, Mar 31, 2012 at 10:20 PM, Terry Reedy tjre...@udel.edu wrote: So I think we should define correct behavior of pytz as use with the latest Olson database. Use with an older version would then be a 'bug' subject to being fixed. On Windows, we could update as needed with every bugfix release. (And give instructions for user update.) On other systems, users can do whatever is appropriate. Or perhaps we could add an 'update tz database' function to the module. Please, don't add updating function to standard lib. It's nightmare for package maintainers. In general I'm +0 for adding tz database to stdlib. -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
Try reducing sys.setcheckinterval(). --Guido van Rossum (sent from Android phone) On Mar 31, 2012 10:45 AM, R. David Murray rdmur...@bitdance.com wrote: On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum gu...@python.org wrote: Here's a different puzzle. Has anyone written a demo yet that provokes this RuntimeError, without cheating? (Cheating would be to mutate the dict from *inside* the __eq__ or __hash__ method.) If you're serious about revisiting this, I'd like to see at least one example of a program that is broken by the change. Otherwise I think the status quo in the 3.3 repo should prevail -- I don't want to be stymied by superstition. I attached an attempt to *deliberately* break the new behaviour to the tracker issue. It isn't actually breaking for me, so I'd like other folks to look at it to see if I missed something in my implementation, of if it's just genuinely that hard to induce the necessary bad timing of a preemptive thread switch. Thanks, Nick. It looks reasonable to me, but I've only given it a quick look so far (I'll try to think about it more deeply later today). If it is indeed hard to provoke, then I'm fine with leaving the RuntimeError as a signal that the application needs to add some locking. My concern was that we'd have working production code that would start breaking. If it takes a *lot* of threads or a *lot* of mutation to trigger it, then it is going to be a lot less likely to happen anyway, since such programs are going to be much more careful about locking anyway. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
2012/3/31 Guido van Rossum gu...@python.org: Try reducing sys.setcheckinterval(). setcheckinterval() is a no-op since the New-GIL. sys.setswitchinterval has superseded it. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
On 03/31/2012 12:47 AM, Victor Stinner wrote: Can you go into more detail about QPC()'s issues? Yes, see the PEP: http://www.python.org/dev/peps/pep-0418/#windows-queryperformancecounter FYI, Victor, the PEP is slightly incomplete. Not that this is your fault--you've done your homework. But I've actually lived through it. I was a professional Win32 developer for 15 years, and I attempted to write a game on Windows back in the early-mid 2000s. On Windows XP, QPC /usually/ uses the ACPI timer in my experience, but sometimes uses RDTSC. Both of these had troubles. With TSC, there's the clock skew between the two cores that they claim was fixed in SP2. (You could also sidestep this problem by setting core affinity to the same core for all your threads that were going to examine the time.) But there's another problem: the TSC frequency actually *does* change when SpeedStep kicks in. I know someone who complained bitterly about running Half-Life 2 on their shiny new laptop, and when it'd overheat SpeedStep would knock down the processor speed and the game's logic update rate would drop in half and now Gordon was running through molasses. With the ACPI timer, that's where you saw the leap-forwards-by-several-seconds-under-heavy-load problem (the cited MSKB article KB274323). That only happened with a specific south bridge chipset, which was Pentium-III-only. I never heard about anyone experiencing that problem--personally I had good experiences with that timer. The downside of the ACPI timer is that it's slow to read; it took just over a microsecond in my experiments. (timeGetTime was 20x faster. I don't know how long GetTickCount takes.) The documentation warnings about timeBeginPeriod is ancient, like Windows 95 era. On any computer running Python 3.3, you can safely call timeBeginPeriod(1) with confidence that you'll get consistent 1ms resolution. Likewise with calling into winmm--it shipped with every OS 3.3 supports. It's just not a big deal and you don't need to mention it in the PEP. I had a hypothetical idea for a hybrid software clock for games that would poll all possible sources of time (RDTSC, QPC, GetTickCount, timeGetTime) and do its level best to create a high-quality synthetic time. Like, if QPC jumped forward by a huge amount, and that jump wasn't corroborated by the other time functions, it'd throw that delta away completely. It'd also notice if QPC's frequency had changed due to SpeedStep and recalibrate. And it'd handle rollover of timeGetTime(). Of course, part of the problem is that calling all these clocks is slow. Another is that if QPC is implemented using RDTSC and RDTSC has problems you're kind of out of options--your best clock at that point only has 1ms accuracy. Anyway I never wound up getting this to work--my attempts were all full of nasty heuristics and the code turned into hash. Maybe someone smarter than me could figure out how to get it to work. Sorry that this is incomplete / dashed off, but I'm still on vacation and it's been a few years since I did Windows timing stuff. And I gotta go to bed--going to Madurodam in the morning! //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
On Apr 1, 2012 8:54 AM, Benjamin Peterson benja...@python.org wrote: 2012/3/31 Guido van Rossum gu...@python.org: Try reducing sys.setcheckinterval(). setcheckinterval() is a no-op since the New-GIL. sys.setswitchinterval has superseded it Ah, that's at least one thing wrong with my initial attempt - I was still thinking in terms of number of bytecodes executed. Old habits die hard :) -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
FYI, Victor, the PEP is slightly incomplete. Sure. What should be added to the PEP? But there's another problem: the TSC frequency actually *does* change when SpeedStep kicks in. I know someone who complained bitterly about running Half-Life 2 on their shiny new laptop, and when it'd overheat SpeedStep would knock down the processor speed and the game's logic update rate would drop in half and now Gordon was running through molasses. Yes, I already changed the PEP to not use QPC anymore for time.monotonic() because it has too many issues. I didn't mention the CPU frequency change issue in the PEP because I failed to find recent information about this issue. Is it an old bug or does it still occur with Windows Vista or Seven? Does Windows Vista and Seven still use TSC or they prefer other hardware clocks like ACPI PMT or HPET? Last info that I found: Historically, the TSC increased with every internal processor clock cycle, but now the rate is usually constant (even if the processor changes frequency) and usually equals the maximum processor frequency. The instructor RDTSC can be used to read this counter. The documentation warnings about timeBeginPeriod is ancient, like Windows 95 era. Which warning? The power consumption issue mentioned in the PEP? Likewise with calling into winmm--it shipped with every OS 3.3 supports. It's just not a big deal and you don't need to mention it in the PEP. I mentioned that the function requires the winmm library because a static or dynamic link to a library can be an issue. Especially if we use this function in Python core. clock_gettime(CLOCK_REALTIME) is not used on Linux for _PyTime_gettimeofday() because it requires to link Python to the rt (real-time) library, but it is used by time.time() (I changed it recently). Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
If we provide a way to check if the monotonic clock is monotonic (or
not), I agree to drop the flag from time.monotonic(fallback=True) and
always fallback. I was never a fan of the truly monotonic clock.
time.clock_info('monotonic')['is_monotonic'] is a good candidate to
store this information.
I updated the PEP to add time.get_clock_info() and to drop the
fallback parameter of time.monotonic() (which now always falls back).
Because monotonic word cannot define time.monotonic() anymore, I
suggest to rename the time.monotonic() function to time.steady(). So
we would have:
- time.steady() may or may not be monotonic, but its is as steady as possible.
- time.get_clock_info('steady')['is_monotonic'] which looks less
surprising than time.get_clock_info('monotonic')['is_monotonic']
It doesn't follow the C++ steady_clock definition, but it looks like
the Boost library doesn't follow the C++ definition... (it uses
CLOCK_MONOTONIC on Linux)
By the way, it now prefer to use CLOCK_MONOTONIC instead of
CLOCK_MONOTONIC_RAW on Linux. It is what I need in practice. If the
hardware clock is a little bit too fast or too slow, NTP adjusts its
rate so a delta of two timestamps is really a number of seconds. It's
not yet written explicitly in the PEP, but the unit of
time.monotonic/time.steady and time.highres is a second.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #14435: Add Misc/NEWS and Misc/ACKS
On Sat, Mar 31, 2012 at 11:10 PM, kristjan.jonsson python-check...@python.org wrote: diff --git a/Misc/ACKS b/Misc/ACKS --- a/Misc/ACKS +++ b/Misc/ACKS @@ -507,6 +507,7 @@ Richard Jones Irmen de Jong Lucas de Jonge +Kristján Valur Jónsson Jens B. Jorgensen John Jorgensen Sijin Joseph *blinks* This must have been one of those cases where everyone assumed your name was already there and never thought to check... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
On Sat, Mar 31, 2012 at 7:37 PM, Victor Stinner
victor.stin...@gmail.com wrote:
If we provide a way to check if the monotonic clock is monotonic (or
not), I agree to drop the flag from time.monotonic(fallback=True) and
always fallback. I was never a fan of the truly monotonic clock.
time.clock_info('monotonic')['is_monotonic'] is a good candidate to
store this information.
I updated the PEP to add time.get_clock_info() and to drop the
fallback parameter of time.monotonic() (which now always falls back).
Because monotonic word cannot define time.monotonic() anymore, I
suggest to rename the time.monotonic() function to time.steady(). So
we would have:
- time.steady() may or may not be monotonic, but its is as steady as possible.
- time.get_clock_info('steady')['is_monotonic'] which looks less
surprising than time.get_clock_info('monotonic')['is_monotonic']
It doesn't follow the C++ steady_clock definition, but it looks like
the Boost library doesn't follow the C++ definition... (it uses
CLOCK_MONOTONIC on Linux)
By the way, it now prefer to use CLOCK_MONOTONIC instead of
CLOCK_MONOTONIC_RAW on Linux. It is what I need in practice. If the
hardware clock is a little bit too fast or too slow, NTP adjusts its
rate so a delta of two timestamps is really a number of seconds. It's
not yet written explicitly in the PEP, but the unit of
time.monotonic/time.steady and time.highres is a second.
Hmm... I believe NTP can also slew the clock to deal with leap seconds
(which the POSIX standard requires must be ignored). That is, when a
leap second is inserted, the clock is supposed to stop value for one
second. What actually happens is that for some time around the leap
second (I've heard maybe a day), the clock is slowed down slightly.
I'm guessing that this affects CLOCK_MONOTONIC but not
CLOCK_MONOTONIC_RAW. Personally I'd rather use the latter -- if I want
to be synchronous with wall clock time, I can just use time.time().
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
