Re: [Python-Dev] time.clock() on windows
Robert Collins robertcollins.net> writes: > > Could you offset it by the system time on the first call? Two problems: - the two measurements are not done simultaneously, so the result *still* does not guarantee you have the same time reference in all processes (but gives you the illusion you do, which is perhaps worse) - adding a precise measure to an imprecise measure doesn't make the result precise, but imprecise (or, rather, precise but inexact); in other words, if the system time only gives a 0.01 second resolution, adding a high-resolution timer only gives you an illusion of accuracy Therefore it seems a very bad solution. The only way, AFAICT, to do this right is for Windows to provide a high-resolution system time. It sounds astonishing that this doesn't exist. Regards Antoine. ___ 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] GIL behaviour under Windows
Sturla Molden molden.no> writes: > > With two threads and a check interval og 100, only 61 of 10 check > intervals failed to produce a thread-switch in the interpreter. I'd call > that rather fair. This number lacks the elapsed time. 61 switches in one second is probably enough, the same amount of switches in 10 or 20 seconds is too small (at least for threads needing good responsivity, e.g. I/O threads). Also, "fair" has to take into account the average latency and its relative stability, which is why I wrote ccbench. Antoine. ___ 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] time.clock() on windows
> -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of Mark Hammond > The thread seems to be at > http://groups.google.com/group/comp.lang.python/browse_frm/thread/be324 > 78a4b8e77b6/816d6228119a3474 > (although I do seem to recall more discussion of the patch which I > currently can't find). I'd be very surprised if any applications rely > on > the fact that each process starts counting at zero, so if someone can > come up with a high-res counter which avoids that artifact I'd expect > it > could be used. The point in question seems to be this this (from the thread): * Need some sort of static "start value", which is set when the process starts, so I can return to Python in seconds. An easy hack is to set this the first time clock() is called, but then it wont reflect any sort of real time - but would be useful for relative times... But the argumentation is flawed. There is an implicit "start" value (technically, CPU powerup). The point concedes that no sort of real time is returned, and so the particular "start" time chosen is immaterial. 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
Re: [Python-Dev] time.clock() on windows
> -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of Robert Collins > > I'd be very surprised if any applications rely on the fact that each > > process starts counting at zero, so if someone can come up with a > > high-res counter which avoids that artifact I'd expect it could be > > used. > > Could you offset it by the system time on the first call? > Since system time has low granularity, it would negate our attemt at having time.clock() reflect the same time between processes. In my opinion, the simplest way is to simply stop setting choosing the first call as a zero base, and use whatever arbitrary time the system has chosen for us. The documentation could then read: "On Windows, this function returns wall-clock seconds elapsed since an arbitrary, system wited, epoch, as a floating point number, based on the Win32 function QueryPerformanceCounter. The resolution is typically better than one microsecond." 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
Re: [Python-Dev] Python Package Management Roadmap in Python Releases
On Wed, Oct 21, 2009 at 08:34:24PM -0400, David Lyon wrote: > I started out some time ago and wrote a Python Package Manager > with wxpython. David, your message appeared in the middle of another thread. Please don't use "Reply" button to start a new thread - send a new message. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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 Package Management Roadmap in Python Releases
On Wed, Oct 21, 2009 at 10:35:49PM -0700, Glenn Linderman wrote: > Maybe what David is missing is that since python-dev is uninterested in > the package management issue, the only remaining way to include package > management in a convenient, single installation, is to > > 1) Create the package management tool > 2) Create a bundled installer that will install both Python, the package > management tool, and any dependencies of the package management tool > 3) Advertise the availability of the bundle, and its usefulness* > 4) See how many users try it out, and as new versions of Python are > created, how many users keep coming back, in preference to the package > management tool free python.org distribution. David, may be my memory betrays me, but I think you ask you question not for the first but for the second, if not the third time. And every time you got exactly this answer - "Create the package management tool and see how many users try it out". Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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 Package Management Roadmap in Python Releases
Glenn Linderman g.nevcal.com> writes: > > Maybe what David is missing is that since python-dev is uninterested in > the package management issue, [...] It's a bit strong to say we are uninterested. Most of us are not interested enough to tackle it ourselves (*), but we are certainly interested in good package management being available for Python. (*) Remember, however, that Tarek and work on Distribute, and also on bringing pieces of setuptools/Distribute functionality into distutils. It's true, however, that it is probably not the place to ask for advice with directions to follow for a yet unwritten piece of software. The only piece of advice (besides "forget Tk and use a modern toolkit" :-)) I could give would be to build on Distribute, rather than reinvent a whole bunch of mechanisms. Regards Antoine. ___ 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] time.clock() on windows
Curt Hagenlocher wrote: > On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou wrote: >> >> Kristján Valur Jónsson ccpgames.com> writes: >>> >>> You are right, on windows time.clock() is based relative to its first call >>> in the process. There is no such promise made on unix. >>> QueryPerformanceCounter() (what time.clock uses()) is a robust high >>> resolution timer that is processor/core independent. It should be >>> possible to use it across different processes too, if this >>> annoying rebasing wasn't there. >> >> Well, could we simply have a high-resolution time.time()? >> Or is Windows just too limited to provide this? > > Presumably you could fake something like this by combining output from > an initial time(), an initial QueryPerformanceCounter() and the > current QueryPerformanceCounter(). But it makes more sense to > understand why someone chose to implement time.clock() on Windows the > way they did -- this seems very broken to me, and I think it should be > changed. > > Of course, there are no doubt people relying on the broken behavior... I'm not sure I understand why time.clock() should be considered broken. time.clock() is used for measuring process CPU time and is usually only used in a relative way, ie. you remember that start value, do something, then subtract the end value from the start value. For absolute CPU time values associated with a process, it's usually better to rely on other APIs such as getrusage() on Unix. You might want to have a look at the systimes module that comes with pybench for some alternative timers: Tools/pybench/systimes.py This module tries to provide a cross-platform API for process and system time: """ systimes() user and system timer implementations for use by pybench. This module implements various different strategies for measuring performance timings. It tries to choose the best available method based on the platforma and available tools. On Windows, it is recommended to have the Mark Hammond win32 package installed. Alternatively, the Thomas Heller ctypes packages can also be used. On Unix systems, the standard resource module provides the highest resolution timings. Unfortunately, it is not available on all Unix platforms. If no supported timing methods based on process time can be found, the module reverts to the highest resolution wall-clock timer instead. The system time part will then always be 0.0. The module exports one public API: def systimes(): Return the current timer values for measuring user and system time as tuple of seconds (user_time, system_time). Copyright (c) 2006, Marc-Andre Lemburg (m...@egenix.com). See the documentation for further information on copyrights, or contact the author. All Rights Reserved. """ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 22 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] time.clock() on windows
On 22/10/2009 8:47 PM, Kristján Valur Jónsson wrote:
The point in question seems to be this this (from the thread):
* Need some sort of static "start value", which is set when the
process starts, so I can return to Python in seconds. An easy hack
is to set this the first time clock() is called, but then it wont
reflect any sort of real time - but would be useful for relative
times...
But the argumentation is flawed.
It was made in the context of the APIs available to implement this. The
code is short-and-sweet in timemodule.c, so please do go ahead and fix
my flawed reasoning.
For reference:
#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
/* Due to Mark Hammond and Tim Peters */
static PyObject *
time_clock(PyObject *self, PyObject *unused)
{
static LARGE_INTEGER ctrStart;
static double divisor = 0.0;
LARGE_INTEGER now;
double diff;
if (divisor == 0.0) {
LARGE_INTEGER freq;
QueryPerformanceCounter(&ctrStart);
if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0) {
/* Unlikely to happen - this works on all intel
machines at least! Revert to clock() */
return PyFloat_FromDouble(((double)clock()) /
CLOCKS_PER_SEC);
}
divisor = (double)freq.QuadPart;
}
QueryPerformanceCounter(&now);
diff = (double)(now.QuadPart - ctrStart.QuadPart);
return PyFloat_FromDouble(diff / divisor);
}
Cheers,
Mark.
___
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] time.clock() on windows
On 22/10/2009 3:45 PM, Robert Collins wrote: On Thu, 2009-10-22 at 15:21 +1100, Mark Hammond wrote: I'd be very surprised if any applications rely on the fact that each process starts counting at zero, so if someone can come up with a high-res counter which avoids that artifact I'd expect it could be used. Could you offset it by the system time on the first call? Off the top of my head, I guess that depends on the actual accuracy required (ie, how many clock ticks elapse between querying the time and the high-resolution timer). Starting at 0 works fine for profiling in a single process, the predominant use-case when this was done; I guess it depends on the specific requirements and time-intervals being dealt with in the cross-process case which determines how suitable that might be? Cheers, Mark ___ 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] time.clock() on windows
M.-A. Lemburg egenix.com> writes: > > I'm not sure I understand why time.clock() should be considered > broken. Because in some cases you want comparable high-resolution numbers from distinct processes. > time.clock() is used for measuring process CPU time According to the docs, under Windows it measures wall-clock time rather than CPU time. Regards Antoine. ___ 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] time.clock() on windows
> -Original Message- > From: Mark Hammond [mailto:mhamm...@skippinet.com.au] > Sent: 22. október 2009 10:58 > To: Kristján Valur Jónsson > Cc: Scott Dial; python-dev@python.org > It was made in the context of the APIs available to implement this. > The > code is short-and-sweet in timemodule.c, so please do go ahead and fix > my flawed reasoning. ... I'm sorry, I don't want to start a flame war here, it just seems that if you need a zero point, and arbitrarily choose the first call to time.clock(), you could just as well use the implicit zero point already provided by the system. > -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of M.-A. Lemburg > I'm not sure I understand why time.clock() should be considered > broken. Ah, well, not broken, but it could be even more useful: If it used the implicit system-wide epoch rather than the one based on the first call within each process, it could be useful for cross-process high-resolution timings. Anyway, it is simple enough to patch it on windows using ctypes if one needs that kind of behaviour: #nuclock.py import ctypes import time counter = ctypes.c_uint64() pcounter = ctypes.byref(counter) ctypes.windll.kernel32.QueryPerformanceFrequency(pcounter) frequency = float(counter.value) QPC = ctypes.windll.kernel32.QueryPerformanceCounter def nuclock(): QPC(pcounter) return float(counter.value)/frequency time.clock = nuclock Cheers, Kristjan ___ 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] Bug 7183 and Python 2.6.4
I'd like to get a second opinion on bug 7183: http://bugs.python.org/issue7183 The Boost folks have reported this as a regression in 2.6.3, making it a candidate for Python 2.6.4. IIUC, the latest version of Boost fixes the problem in their code, but if it really is a regression it could affect other projects and should probably be fixed. Robert Collins from the Bazaar team pinged me on IRC and originally thought that they'd been bitten by this problem too, though he looked around and determined it probably did /not/ affect them after all. So we have only anecdotal evidence of a problem, and no reproducible test case. If the Python 2.6.4 release is to be held up for this issue, we need to know today or tomorrow. Come the weekend, I'm going ahead with the tag and release. Holding up the release will mean another release candidate, and a wait of another week for the final. So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix? Thanks, -Barry PGP.sig Description: This is a digitally signed message part ___ 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] Bug 7183 and Python 2.6.4
2009/10/22 Barry Warsaw : > So does anybody else think bug 7183 should be a release blocker for 2.6.4 > final, or is even a legitimate but that we need to fix? I think it cannot hold up a release with out a reproducible code snippet. -- 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] Interest in integrating C decimal module into Python?
Mark Dickinson wrote: > Thanks, Antoine! With SLOCCount I can revise my earlier numbers, as well: > Here's Stefan Krah's mpdecimal, version 0.80: > > SLOCDirectory SLOC-by-Language (Sorted) > 21445 top_dir ansic=21267,sh=105,python=55,asm=18 > 6238python python=6177,java=43,sh=18 > 1403tests ansic=1356,sh=47 > 476 literature lisp=476 > 274 cmd ansic=274 > 11 tools sh=11 > 0 doc (none) I would say that the relevant code is less than that: The module code is counted twice (fastdec2.c, fastdec3.c), and sloccount counts the inline functions in the mpdecimal*.h header files. So, after removing fastdec3.c, mpdecimal32.h, mpdecimal32vc.h, mpdecimal64vc.h, I get: SLOCDirectory SLOC-by-Language (Sorted) 13702 top_dir ansic=13524,sh=105,python=55,asm=18 6238python python=6177,java=43,sh=18 1403tests ansic=1356,sh=47 476 literature lisp=476 274 cmd ansic=274 11 tools sh=11 0 doc (none) Totals grouped by language (dominant language first): ansic:15154 (68.56%) python:6232 (28.19%) lisp: 476 (2.15%) sh: 181 (0.82%) java:43 (0.19%) asm: 18 (0.08%) Therefore, my estimate is between 12660 and 13702 lines, depending on whether to count the remaining mpdecimal64.h (Most inline functions in this header file are signaling wrappers around the quiet functions and are not necessary for the module). If one takes out all library functions that the module does not use, I'm sure it could be condensed to ~11500 lines. This is comparable to the expat directory in Modules/: SLOCDirectory SLOC-by-Language (Sorted) 11406 expat ansic=11406 Stefan Krah ___ 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] Interest in integrating C decimal module into Python?
Mark Dickinson wrote: > > 2. Would fastdec - after achieving full decimal.py compatibility - be > > a serious candidate? > > Definitely. As far as I know it's the only real candidate for a full > C version of decimal right now. Other possibilities that I'm aware of: > > * I think Raymond Hettinger is working on a C version of decimal. > I'm not sure what its current status is. Raymond? > > * There's a partially complete rewrite of decimal in C in the sandbox, > dating from the Need for Speed sprint in 2006: > > * Wrapping the decNumber library directly would make some sense, > but I think licensing issues rule this out. I hope I'm not spreading misinformation, but I see two problems with the use of decNumber as an arbitrary precision library. First, the algorithms are not optimized for large numbers. Then, you have to define the maximum length of the coefficient *at compile time* by setting DECNUMDIGITS. > It's difficult to gauge the likelihood of eventual acceptance in advance, > though. Maybe writing a PEP would be an efficient use of time in this > regard? There are certainly some open issues (e.g., what to do with > the existing Python module; what should other Python implementations > do). Good, I'll do that. I mainly wanted to find out if there is fundamental opposition against C-decimal in the standard library, but this does not seem to be the case. > I think my biggest concern is maintenance: we'd be replacing > 8500 lines of Python code in a single file, that several of the > current core developers understand well, with 3 (Stefan, is > that about accurate?) lines of C in several files, that presumably > none of the current core devs is familiar with right now. Ok, I think we could say that the sloc-counts are around 2600 lines of Python vs. around 11500-12500 lines of C. > What happens when (e.g.,) the number-theoretic transform needs > updating for one reason or another? Stefan, do you see yourself > having time to spend on maintenance of this code for the > forseeable future? Yes. Generally speaking, I expect the code to be low-maintenance. It would be even easier if all major compilers supported exact width C99 types and __uint128_t, but this is wishful thinking. Stefan Krah ___ 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] Bug 7183 and Python 2.6.4
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote: 2009/10/22 Barry Warsaw : So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix? I think it cannot hold up a release with out a reproducible code snippet. It may not be reproducible in standard Python, see David's follow up to the issue. If that holds true and we can't reproduce it, I agree we should not hold up the release for this. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] nonlocal keyword in 2.x?
On Wed, Oct 21, 2009 at 10:56 PM, Mike Krell wrote: > Is there any possibility of backporting support for the nonlocal keyword > into a 2.x release? I see it's not in 2.6, but I don't know if that was an > intentional design choice or due to a lack of demand / round tuits. I'm > also not sure if this would fall under the scope of the proposed moratorium > on new language features (although my first impression was that it could be > allowed since it already exists in python 3. > > One of my motivations for asking is a recent blog post by Fernando Perez of > IPython fame that describes an interesting decorator-based idiom inspired by > Apple's Grand Central Dispatch which would allow many interesting > possibilities for expressing parallelization and other manipulations of > execution context for blocks of python code. Unfortunately, using the > technique to its fullest extent requires the nonlocal keyword. > > The blog post is here: > https://cirl.berkeley.edu/fperez/py4science/decorators.html > Just as a note, the nonlocal there is not a requirement... You can just create a mutable object there and change that object (so, you don't need to actually rebind the object in the outer scope). E.g.: instead of creating a float in the context, create a list with a single float and change the float in the list (maybe the nonlocal would be nicer, but it's certainly still usable) Cheers, Fabio ___ 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] PyErr_NewExceptionWithDoc
Hi, issue #7033 proposes a new C API that creates a new exception class with a docstring. Since exception classes should be documented, and adding the docstring after creating is not a one-liner, I would say it is a useful addition. What do you all think? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Interest in integrating C decimal module into Python?
Stefan Krah wrote: > Mark Dickinson wrote: >> I think my biggest concern is maintenance: we'd be replacing >> 8500 lines of Python code in a single file, that several of the >> current core developers understand well, with 3 (Stefan, is >> that about accurate?) lines of C in several files, that presumably >> none of the current core devs is familiar with right now. > > Ok, I think we could say that the sloc-counts are around 2600 lines of > Python vs. around 11500-12500 lines of C. If maintenance is an issue, I would actually propose to compile the existing decimal.py using Cython (works with a few trivial modifications), add a few type decorators at the hot spots to make them really fast, and then use that as both the Python implementation and fast binary module. 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
[Python-Dev] readonly __doc__
Speaking of the __doc__ property, I just noticed the following thing on py3k: >>> class C: pass ... >>> C.__doc__ = "hop" Traceback (most recent call last): File "", line 1, in AttributeError: attribute '__doc__' of 'type' objects is not writable Is this deliberate? Antoine. ___ 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] readonly __doc__
> Speaking of the __doc__ property, I just noticed the following thing on > py3k: > class C: pass > ... C.__doc__ = "hop" > Traceback (most recent call last): > File "", line 1, in > AttributeError: attribute '__doc__' of 'type' objects is not writable Happens also with new style classes in python 2.x: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class C(object): pass ... >>> C.__doc__ = 'hello' Traceback (most recent call last): File "", line 1, in AttributeError: attribute '__doc__' of 'type' objects is not writable >>> But not with old style classes: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class C: pass ... >>> C.__doc__ = 'hello' >>> Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Bug 7183 and Python 2.6.4
On Oct 22, 2009, at 11:04 AM, Barry Warsaw wrote: On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote: 2009/10/22 Barry Warsaw : So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix? I think it cannot hold up a release with out a reproducible code snippet. It may not be reproducible in standard Python, see David's follow up to the issue. If that holds true and we can't reproduce it, I agree we should not hold up the release for this. >>> class Foo(property): ... __slots__=[] ... >>> x=Foo() >>> x.__doc__ = "asdf" Traceback (most recent call last): File "", line 1, in AttributeError: 'Foo' object attribute '__doc__' is read-only You can't add arbitrary attributes to instances, since some instances don't have the slot to put them in. Is that an equivalent demonstration to that which boost runs into? (except, it's using a C type not a python type). James ___ 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] GIL behaviour under Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: > Sturla Molden molden.no> writes: >> With two threads and a check interval og 100, only 61 of 10 check >> intervals failed to produce a thread-switch in the interpreter. I'd call >> that rather fair. > > This number lacks the elapsed time. 61 switches in one second is probably > enough, the same amount of switches in 10 or 20 seconds is too small (at least > for threads needing good responsivity, e.g. I/O threads). I read Sturla as saying there were 99,939 switches out of a possible 100,000, with sys.checkinterval set to 100. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrgkO4ACgkQ+gerLs4ltQ4yZgCfZyRfWKPBzRb52v7RtLAMlNts SOIAnjgxqJ1Wovas5cHoju8kwbvn/9Es =2SDx -END PGP SIGNATURE- ___ 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] readonly __doc__
On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou wrote: > > Speaking of the __doc__ property, I just noticed the following thing on py3k: > class C: pass > ... C.__doc__ = "hop" > Traceback (most recent call last): > File "", line 1, in > AttributeError: attribute '__doc__' of 'type' objects is not writable > > Is this deliberate? Yes. -- --Guido van Rossum (home page: http://www.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] GIL behaviour under Windows
Tres Seaver palladion.com> writes: > > I read Sturla as saying there were 99,939 switches out of a possible > 100,000, with sys.checkinterval set to 100. Oops, you're right. But depending on the elapsed time (again :-)), it may be too high, because too many switches per second will add a lot of overhead and decrease performance. Regards Antoine. ___ 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] Bug 7183 and Python 2.6.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: > On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote: > >> 2009/10/22 Barry Warsaw : >>> So does anybody else think bug 7183 should be a release blocker for >>> 2.6.4 >>> final, or is even a legitimate but that we need to fix? >> I think it cannot hold up a release with out a reproducible code >> snippet. > > It may not be reproducible in standard Python, see David's follow up > to the issue. If that holds true and we can't reproduce it, I agree > we should not hold up the release for this. The fix for 5890 has a funny "smell" to me: copying __doc__ into the instance dict just feels wrong. How does that work with a pure Python class using slots? E.g.: class MyProp(property): pass class Foo(object): @property def bar(self): '''Get a bar.''' @MyProp def baz(self): '''Get a baz.''' print Foo.bar.__doc__ print Foo.baz.__doc__ class SlottedFoo(object): __slots__ = () @property def bar(self): '''Get a bar.''' @MyProp def baz(self): '''Get a baz.''' print SlottedFoo.bar.__doc__ print SlottedFoo.baz.__doc__ That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrgk3AACgkQ+gerLs4ltQ6n7gCgmV3zWTazLTHWfmD2zul0BTnF 9dkAn38HXKw4RPwWV8Ht4hUGBC00IB2N =ssdH -END PGP SIGNATURE- ___ 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] readonly __doc__
On Thu, Oct 22, 2009 at 7:12 PM, Guido van Rossum wrote: > Yes. Why? --yuv ___ 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] readonly __doc__
Guido van Rossum python.org> writes: > > On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou pitrou.net> wrote: > > > > Speaking of the __doc__ property, I just noticed the following thing on py3k: > > > class C: pass > > ... > C.__doc__ = "hop" > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: attribute '__doc__' of 'type' objects is not writable > > > > Is this deliberate? > > Yes. I might add why I was asking this question. I was trying to demonstrate the use of class decorators and the simplest example I found was to add a docstring to the class. And I was surprised when I saw the following fail with the aforementioned exception: def classdeco(cls): cls.__doc__ = "decorated!" return cls @classdeco class C: pass Regards Antoine. ___ 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-ideas] Remove GIL with CAS instructions?
I'd just like to point out some previous discussion about implementing the GIL as a critical section or semaphore on Windows since it's come up here (although not quite the center of the OP's proposal AFAICS): http://bugs.python.org/issue6132 http://mail.python.org/pipermail/python-dev/2009-May/089746.html Some of this is more low-level. I did see higher performance when using non-Event objects, although I have not had time to follow up and do a deeper analysis. The GIL flashing "problem" with critical sections can very likely be rectified with a call to Sleep(0) or YieldProcessor() for those who are worried about it. On the subject of fairness, I tested various forms of the GIL on my multi-threaded ISAPI extension, where every millisecond counts when under high concurrency, and fairness wasn't an issue for single- or multi-core systems. It may be anecdotal, but it also may be that the issue is somewhat over-blown. It seems like these discussions come up in one form or another a few times a year and don't really get anywhere - probably because many people find that it's easier to just run one instance of Python on each core/processor. IPC is cheap (cPickle rocks!), and Python's memory footprint is acceptable by today's standards. Still, it is an interesting topic to many, myself included. Also, many people keep talking about inefficiencies due to threads waking up to a locked GIL. I'd like to see examples of this- most of the time, the OS should know that the thread is contending on the lock object and it is skipped over. Granted, a thread may wake up just to release the GIL shortly thereafter, but that's why sys.setcheckinterval() is there for us to tinker with. Anyway, enough of my $0.02. - Phillip 2009/10/21 John Arbash Meinel : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristján Valur Jónsson wrote: > ... > >> This depends entirely on the platform and primitives used to implement the >> GIL. >> I'm interested in windows. There, I found this article: >> http://fonp.blogspot.com/2007/10/fairness-in-win32-lock-objects.html >> So, you may be on to something. Perhaps a simple C test is in order then? >> >> I did that. I found, on my dual-core vista machine, that running "release", >> that both Mutexes and CriticalSections behaved as you describe, with no >> "fairness". Using a "semaphore" seems to retain fairness, however. >> "fairness" was retained in debug builds too, strangely enough. >> >> Now, Python uses none of these. On windows, it uses an "Event" object >> coupled with an atomically updated counter. This also behaves fairly. >> >> The test application is attached. >> >> >> I think that you ought to sustantiate your claims better, maybe with a >> specific platform and using some test like the above. >> >> On the other hand, it shows that we must be careful what we use. There has >> been some talk of using CriticalSections for the GIL on windows. This test >> ought to show the danger of that. The GIL is different than a regular lock. >> It is a reverse-lock, really, and therefore may need to be implemented in >> its own special way, if we want very fast mutexes for the rest of the system >> (cc to python-dev) >> >> Cheers, >> >> Kristján > > I can compile and run this, but I'm not sure I know how to interpret the > results. If I understand it correctly, then everything but "Critical > Sections" are fair on my Windows Vista machine. > > To run, I changed the line "#define EVENT" to EVENT, MUTEX, SEMAPHORE > and CRIT. I then built and ran in "Release" environment (using VS 2008 > Express) > > For all but CRIT, I saw things like: > thread 5532 reclaims GIL > thread 5532 working 51234 units > thread 5532 worked 51234 units: 1312435761 > thread 5532 flashing GIL > thread 5876 reclaims GIL > thread 5876 working 51234 units > thread 5876 worked 51234 units: 1312435761 > thread 5876 flashing GIL > > Where there would be 4 lines for one thread, then 4 lines for the other > thread. > > for CRIT, I saw something more like 50 lines for one thread, and then 50 > lines for the other thread. > > This is Vista Home Basic, and VS 2008 Express Edition, with a 2-core > machine. > > John > =:-> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrfKFAACgkQJdeBCYSNAANbuQCgudU0IChylofTwvUk/JglChBd > 9gsAoIJHj63/CagKpduUsd68HV8pP3QX > =CuUj > -END PGP SIGNATURE- > ___ > 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/phillip.sitbon%2Bpython-dev%40gmail.com > ___ 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%4
Re: [Python-Dev] readonly __doc__
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules. On Thu, Oct 22, 2009 at 10:25 AM, Antoine Pitrou wrote: > Guido van Rossum python.org> writes: >> >> On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou pitrou.net> > wrote: >> > >> > Speaking of the __doc__ property, I just noticed the following thing > on py3k: >> > >> class C: pass >> > ... >> C.__doc__ = "hop" >> > Traceback (most recent call last): >> > File "", line 1, in >> > AttributeError: attribute '__doc__' of 'type' objects is not writable >> > >> > Is this deliberate? >> >> Yes. > > I might add why I was asking this question. I was trying to demonstrate the > use > of class decorators and the simplest example I found was to add a docstring to > the class. And I was surprised when I saw the following fail with the > aforementioned exception: > > def classdeco(cls): > cls.__doc__ = "decorated!" > return cls > > @classdeco > class C: > pass > > > Regards > > Antoine. > > > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.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] readonly __doc__
On Thu, Oct 22, 2009 at 1:25 PM, Antoine Pitrou wrote: .. > I might add why I was asking this question. I was trying to demonstrate the > use > of class decorators and the simplest example I found was to add a docstring to > the class. I always thought that read-only __doc__ was an artifact of new classes evolving from (C-implemented) types. IIRC, NumPy project implemented a somewhat elaborate hack to allow docstrings to be added to C-implemented classes in a .py file. ___ 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] readonly __doc__
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote: Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules. Maybe we could add a ticket to flag this in the docs. Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't? Any others that deserve special notice, while we're at it? Thanks, S ___ 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] GIL behaviour under Windows
I know I already posted some relevant threads to the other discussion, but I wanted to point out a couple of specific comments on GIL fairness from the discussion: http://mail.python.org/pipermail/python-dev/2009-May/089752.html http://mail.python.org/pipermail/python-dev/2009-May/089755.html - Phillip On Thu, Oct 22, 2009 at 10:16 AM, Antoine Pitrou wrote: > Tres Seaver palladion.com> writes: >> >> I read Sturla as saying there were 99,939 switches out of a possible >> 100,000, with sys.checkinterval set to 100. > > Oops, you're right. > But depending on the elapsed time (again :-)), it may be too high, because > too many switches per second will add a lot of overhead and decrease > performance. > > Regards > > Antoine. > > > ___ > 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/phillip.sitbon%2Bpython-dev%40gmail.com > ___ 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] PyErr_NewExceptionWithDoc
On Thu, Oct 22, 2009 at 08:43, Georg Brandl wrote: > Hi, > > issue #7033 proposes a new C API that creates a new exception class with > a docstring. Since exception classes should be documented, and adding > the docstring after creating is not a one-liner, I would say it is a useful > addition. What do you all think? > > Seems fine to me. > Georg > > -- > Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. > Four shall be the number of spaces thou shalt indent, and the number of thy > indenting shall be four. Eight shalt thou not indent, nor either indent > thou > two, excepting that thou then proceed to four. Tabs are right out. > > ___ > 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/brett%40python.org > ___ 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] Bug 7183 and Python 2.6.4
On Oct 22, 2009, at 1:16 PM, Tres Seaver wrote: That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can. Agreed. I've knocked it down from release-blocker. -Barryu PGP.sig Description: This is a digitally signed message part ___ 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] readonly __doc__
On Thu, Oct 22, 2009 at 11:18, sstein...@gmail.com wrote: > > On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote: > > Well __doc__ isn't a normal attribute -- it doesn't follow inheritance >> rules. >> > > Maybe we could add a ticket to flag this in the docs. > > Sure, go for it. > Is __doc__ not normal due to its general underscorishness, or is it not > normal because it isn't? > > I honestly don't follow that sentence. But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with. > Any others that deserve special notice, while we're at it? > Don't know. ___ 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] Bug 7183 and Python 2.6.4
On Thu, 22 Oct 2009 at 13:16, Tres Seaver wrote: The fix for 5890 has a funny "smell" to me: copying __doc__ into the instance dict just feels wrong. How does that work with a pure Python class using slots? E.g.: It doesn't. There's even a test to make sure it doesn't :) (It raises an attribute error.) __doc__ is a funny beast. If someone can come up with a better fix for 5890, that would be great. --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] Add const to python API - issue 6952
On 21 Oct 2009, at 06:15, Martin v. Löwis wrote: I suggest following POSIX's lead and omitted the const in these cases. Ah... Yes I see this in strstr for example. Thanks, that sounds reasonable. This is basically what I have done in the patch I hope. I have updated the patch to include a comment explaining why output param is char ** and the need for a cast. Barry ___ 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] readonly __doc__
On Oct 22, 2009, at 2:39 PM, Brett Cannon wrote: On Thu, Oct 22, 2009 at 11:18, sstein...@gmail.com > wrote: On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote: Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules. Maybe we could add a ticket to flag this in the docs. Sure, go for it. Filed: http://bugs.python.org/issue7186 Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't? I honestly don't follow that sentence. It means, is it special because it's a "special" i.e. __X__ type attribute or because of something special about __doc__ itself, independent of it being a "special attribute". But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with. Any others that deserve special notice, while we're at it? Don't know. Ok, issue recorded. Thanks, S ___ 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] Bug 7183 and Python 2.6.4
Tres Seaver schrieb: > Barry Warsaw wrote: >> On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote: > >>> 2009/10/22 Barry Warsaw : So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix? >>> I think it cannot hold up a release with out a reproducible code >>> snippet. > >> It may not be reproducible in standard Python, see David's follow up >> to the issue. If that holds true and we can't reproduce it, I agree >> we should not hold up the release for this. > > The fix for 5890 has a funny "smell" to me: copying __doc__ into the > instance dict just feels wrong. How does that work with a pure Python > class using slots? E.g.: > > class MyProp(property): > pass > > class Foo(object): > @property > def bar(self): > '''Get a bar.''' > > @MyProp > def baz(self): > '''Get a baz.''' > > print Foo.bar.__doc__ > print Foo.baz.__doc__ > > class SlottedFoo(object): > __slots__ = () > @property > def bar(self): > '''Get a bar.''' > > @MyProp > def baz(self): > '''Get a baz.''' > > print SlottedFoo.bar.__doc__ > print SlottedFoo.baz.__doc__ Works just fine. I think you meant class MyProp(property): __slots__ = () Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Bug 7183 and Python 2.6.4
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ... > That being said, I can't this bug as a release blocker: people can > either upgrade to super-current Boost, or stick with 2.6.2 until they can. Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :( -Rob signature.asc Description: This is a digitally signed message part ___ 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] nonlocal keyword in 2.x?
Mike Krell wrote: > Is there any possibility of backporting support for the nonlocal keyword > into a 2.x release? If so, only into 2.7. Can you please explain why it would be desirable to do that? 2.7 will likely be the last 2.x release, so only a fairly small portion of the applications would be actually able to use this (or any other new feature added to 2.7): most code supporting 2.x will also have to support 2.6, so the keyword won't be available to such code, anyway. 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] Bug 7183 and Python 2.6.4
2009/10/22 Robert Collins : > On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: > ... >> That being said, I can't this bug as a release blocker: people can >> either upgrade to super-current Boost, or stick with 2.6.2 until they can. > > Thats the challenge Ubuntu faces: > https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 > > We've just announced our Karmic RC, boost 1.40 isn't released, and > python 2.6.3 doesn't work with a released boost :( ?? Boost 1.40 was released on 27th August, according to www.boost.org... Paul. ___ 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] Bug 7183 and Python 2.6.4
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote: On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ... That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can. Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :( Aren't we stuck either way though? :( -Barry PGP.sig Description: This is a digitally signed message part ___ 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] Bug 7183 and Python 2.6.4
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote: On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ... That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can. Thats the challenge Ubuntu faces: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 We've just announced our Karmic RC, boost 1.40 isn't released, and python 2.6.3 doesn't work with a released boost :( If I were running a Linux distro, I'd revert the patch in 2.6.3. And if I were running a Python release process, I'd revert that patch for python 2.6.4, and reopen the bug that it fixed, so a less-breaky patch can be made. James ___ 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] nonlocal keyword in 2.x?
On 08:24 pm, mar...@v.loewis.de wrote: Mike Krell wrote: Is there any possibility of backporting support for the nonlocal keyword into a 2.x release? If so, only into 2.7. Can you please explain why it would be desirable to do that? 2.7 will likely be the last 2.x release, so only a fairly small portion of the applications would be actually able to use this (or any other new feature added to 2.7): most code supporting 2.x will also have to support 2.6, so the keyword won't be available to such code, anyway. For the same reason that it is desirable to backport all of the other changes from 3.x - because it makes the 2.x to 3.x transition easier. If Python 2.7 supports the nonlocal keyword, then 2.7 becomes that much better of a stepping stone towards 3.x. You've suggested that most 2.x code will have to support 2.6 and so won't be able to use the nonlocal keyword even if it is added to 2.7. This precise argument could be applied to all of the features in 2.6 which aim to bring it closer to 3.x. Any program which must retain Python 2.5 compatibility will not be able to use them. Yet 2.6 is a more useful stepping stone towards 3.x than 2.5 is. So yes, it would be quite desirable to see nonlocal and as many other 3.x features as possible backported for 2.7. And depending on how close 2.7 manages to get, it may make sense to backport anything that doesn't make it into 2.7 for a 2.8 release. The 3.x transition is *hard*. Anything that makes it easier is good. Jean-Paul ___ 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] time.clock() on windows
Kristján Valur Jónsson wrote: > Yes. The problem with QPC is that although it has very high > resolution, it is not precise in the long term. And > GetSystemTimeAsFileTime() is high precision in the long term but only > updated evey 20ms or so. In EVE Online we use a combination of the > two for high resolution, long term precision. But I'm not happy with > the way I'm doing it. It needs some sort of smoothing of course. > I've even played with using Kalman filtering to do it... The idea is > to use the low frequency timer to apply correction coefficients to > the high frequency timer, yet keep the flow of time smooth (no > backwards jumps because of corrections.). An optimal solution has so > far eluded me. That sounds very similar to the problem spec for system time corrections in Network Time Protocol client implementations. Perhaps the time drifting algorithms in the NTP specs are relevant? Or are they too slow to correct discrepancies? 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] readonly __doc__
Brett Cannon python.org> writes: > > > I honestly don't follow that sentence. But __doc__ is special because of its > use; documenting how to use of an object. In this case when you call > something like help() on an instance of an object it skips the instance's > value for __doc__ and goes straight to the defining class and stops there as > you don't care how a subclass says to use itself as that is not what you are > working with. I don't really understand how this explains the read-only __doc__. I am talking about modifying __doc__ on a class, not on an instance. (sure, a new-style class is also an instance of type, but still...) Antoine. ___ 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] Bug 7183 and Python 2.6.4
On Thu, 2009-10-22 at 21:27 +0100, Paul Moore wrote: > 2009/10/22 Robert Collins : > > On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: > > ... > >> That being said, I can't this bug as a release blocker: people can > >> either upgrade to super-current Boost, or stick with 2.6.2 until they can. > > > > Thats the challenge Ubuntu faces: > > https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 > > > > We've just announced our Karmic RC, boost 1.40 isn't released, and > > python 2.6.3 doesn't work with a released boost :( > > ?? Boost 1.40 was released on 27th August, according to www.boost.org... Oh bah, teach me to trust comments in bug reports :) Still, a full release is high risk, one of the Ubuntu devs is looking for the single patch they added to fix things. -Rob signature.asc Description: This is a digitally signed message part ___ 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] nonlocal keyword in 2.x?
exar...@twistedmatrix.com wrote: > On 08:24 pm, mar...@v.loewis.de wrote: >> Mike Krell wrote: >>> Is there any possibility of backporting support for the nonlocal keyword >>> into a 2.x release? >> >> If so, only into 2.7. Can you please explain why it would be desirable >> to do that? 2.7 will likely be the last 2.x release, so only a fairly >> small portion of the applications would be actually able to use this (or >> any other new feature added to 2.7): most code supporting 2.x will also >> have to support 2.6, so the keyword won't be available to such code, >> anyway. > > For the same reason that it is desirable to backport all of the other > changes from 3.x - because it makes the 2.x to 3.x transition easier. Hmm. Really? > If Python 2.7 supports the nonlocal keyword, then 2.7 becomes that much > better of a stepping stone towards 3.x. What use has such a stepping stone? Why, and (more importantly) when would anybody currently supporting 2.x give up 2.6 and earlier, and only support 2.7? And, if they chose to do so, why would they not move the code base to 3.x right away? > You've suggested that most 2.x code will have to support 2.6 and so > won't be able to use the nonlocal keyword even if it is added to 2.7. Correct. > This precise argument could be applied to all of the features in 2.6 > which aim to bring it closer to 3.x. Not so. One of the features added to 2.6 was the 3k warning. This warning can be used without any modification to the code. So code can run on 2.6 and use the feature, while running unmodified on 2.5 and earlier (not using it). As for actual language and library changes (such as any new future import): there was indeed little point adding them. However, given that the possible migration paths weren't as clear back then as they are now, it is understandable that people considered this a viable path. In addition, for 2.6, it's a bit more realistic to assume that people might drop 2.5 support and still support 2.x for some more time (in particular as people wouldn't rule out a 2.8 release back then, either). > Any program which must retain > Python 2.5 compatibility will not be able to use them. Yet 2.6 is a > more useful stepping stone towards 3.x than 2.5 is. I disagree fairly much (except that the 3k warnings probably *are* useful - even though I haven't ever used them myself). > So yes, it would be quite desirable to see nonlocal and as many other > 3.x features as possible backported for 2.7. And depending on how close > 2.7 manages to get, it may make sense to backport anything that doesn't > make it into 2.7 for a 2.8 release. There might not be a 2.8 release at all, though. > The 3.x transition is *hard*. Anything that makes it easier is good. I agree. I question whether backporting features actually makes the transition easier. In addition, in the *specific* case: the nonlocal keyword isn't necessary for a transition *at all*. Code that currently works without it won't need it when ported to 3.x. You may not be able to use it while maintaining 2.x and 3.x simultaneously, but you can certainly do the transition just fine without it. 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] readonly __doc__
On Thu, Oct 22, 2009 at 1:49 PM, Antoine Pitrou wrote: > Brett Cannon python.org> writes: >> I honestly don't follow that sentence. But __doc__ is special because of its >> use; documenting how to use of an object. In this case when you call >> something like help() on an instance of an object it skips the instance's >> value for __doc__ and goes straight to the defining class and stops there as >> you don't care how a subclass says to use itself as that is not what you are >> working with. > > I don't really understand how this explains the read-only __doc__. > I am talking about modifying __doc__ on a class, not on an instance. > (sure, a new-style class is also an instance of type, but still...) Antoine, it's not clear from the questions you're asking whether you've read the code in typobject.c that implements __doc__ or not. -- --Guido van Rossum (home page: http://www.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] readonly __doc__
Le jeudi 22 octobre 2009 à 13:59 -0700, Guido van Rossum a écrit : > > I don't really understand how this explains the read-only __doc__. > > I am talking about modifying __doc__ on a class, not on an instance. > > (sure, a new-style class is also an instance of type, but still...) > > Antoine, it's not clear from the questions you're asking whether > you've read the code in typobject.c that implements __doc__ or not. Ah, well I haven't :-/ My bad. Regards Antoine. ___ 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] nonlocal keyword in 2.x?
Martin v. Löwis wrote: exar...@twistedmatrix.com wrote: On 08:24 pm, mar...@v.loewis.de wrote: Mike Krell wrote: Is there any possibility of backporting support for the nonlocal keyword into a 2.x release? If so, only into 2.7. Can you please explain why it would be desirable to do that? 2.7 will likely be the last 2.x release, so only a fairly small portion of the applications would be actually able to use this (or any other new feature added to 2.7): most code supporting 2.x will also have to support 2.6, so the keyword won't be available to such code, anyway. For the same reason that it is desirable to backport all of the other changes from 3.x - because it makes the 2.x to 3.x transition easier. Hmm. Really? If Python 2.7 supports the nonlocal keyword, then 2.7 becomes that much better of a stepping stone towards 3.x. What use has such a stepping stone? Why, and (more importantly) when would anybody currently supporting 2.x give up 2.6 and earlier, and only support 2.7? And, if they chose to do so, why would they not move the code base to 3.x right away? From the Django roadmap for supporting 3.0, using 2.6 as a stepping stone (and if 2.7 was a *better* stepping stone then it would make it easier): http://groups.google.com/group/django-developers/msg/0888b1c8f2518059? * First half of 2009: Django 1.1 is released, with a notification that it will be the final release supporting Python 2.3. * Second half of 2009: Django 1.2 is released, drops Python 2.3 support and is the final release supporting Python 2.4. * First half of 2010: Django 1.3 is released, drops Python 2.4 support and is the final release supporting Python 2.5. * Second half of 2010: Django 1.4 is released and drops Python 2.5 support. This gets us to a situation where, about a year after the release of Python 3.0, Django will be ready to make the transition -- the only 2.x Python we'll be supporting is Python 2.6, and 2to3 plus manual effort and available supporting libraries should make it possible to also run Django on Python 3.0 either at that point or not long after. From there, 2.6 support can be dropped whenever convenient, and Django can move to running only on Python 3.x at whatever time is judged appropriate. All the best, Michael Foord You've suggested that most 2.x code will have to support 2.6 and so won't be able to use the nonlocal keyword even if it is added to 2.7. Correct. This precise argument could be applied to all of the features in 2.6 which aim to bring it closer to 3.x. Not so. One of the features added to 2.6 was the 3k warning. This warning can be used without any modification to the code. So code can run on 2.6 and use the feature, while running unmodified on 2.5 and earlier (not using it). As for actual language and library changes (such as any new future import): there was indeed little point adding them. However, given that the possible migration paths weren't as clear back then as they are now, it is understandable that people considered this a viable path. In addition, for 2.6, it's a bit more realistic to assume that people might drop 2.5 support and still support 2.x for some more time (in particular as people wouldn't rule out a 2.8 release back then, either). Any program which must retain Python 2.5 compatibility will not be able to use them. Yet 2.6 is a more useful stepping stone towards 3.x than 2.5 is. I disagree fairly much (except that the 3k warnings probably *are* useful - even though I haven't ever used them myself). So yes, it would be quite desirable to see nonlocal and as many other 3.x features as possible backported for 2.7. And depending on how close 2.7 manages to get, it may make sense to backport anything that doesn't make it into 2.7 for a 2.8 release. There might not be a 2.8 release at all, though. The 3.x transition is *hard*. Anything that makes it easier is good. I agree. I question whether backporting features actually makes the transition easier. In addition, in the *specific* case: the nonlocal keyword isn't necessary for a transition *at all*. Code that currently works without it won't need it when ported to 3.x. You may not be able to use it while maintaining 2.x and 3.x simultaneously, but you can certainly do the transition just fine without it. 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] GIL behaviour under Windows
Antoine Pitrou skrev: This number lacks the elapsed time. 61 switches in one second is probably enough, the same amount of switches in 10 or 20 seconds is too small (at least for threads needing good responsivity, e.g. I/O threads). Also, "fair" has to take into account the average latency and its relative stability, which is why I wrote ccbench. Since I am a scientist and statistics interests me, let's do this properly :-) Here is a suggestion: _Py_Ticker is a circular variable. Thus, it can be transformed to an angle measured in radians, using: a = 2 * pi * _Py_Ticker / _Py_CheckInterval With simultaneous measurements of a, check interval count x, and time y (µs), we can fit the multiple regression: y = b0 + b1*cos(a) + b2*sin(a) + b3*x + err using some non-linear least squares solver. We can then extract all the statistics we need on interpreter latencies for "ticks" with and without periodic checks. On a Python setup with many missed thread switches (pthreads according to D. Beazley), we could just extend the model to take into account successful and unsccessful check intervals: y = b0 + b1*cos(a) + b2*sin(a) + b3*x1 + b4*x2 + err where x1 being successful thread switches and x2 being missed thread switches. But at least on Windows we can use the simpler model. The reason why multiple regression is needed, is that the record method of my GIL_Battle class is not called on every interpreter tick. I thus cannot measure precicesly each latency, which I could have done with a direct hook into ceval.c. So statistics to the rescue. But on the bright side, it reduces the overhead of the profiler. Would that help? Sturla Molden ___ 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-ideas] Remove GIL with CAS instructions?
Phillip Sitbon skrev: Some of this is more low-level. I did see higher performance when using non-Event objects, although I have not had time to follow up and do a deeper analysis. The GIL flashing "problem" with critical sections can very likely be rectified with a call to Sleep(0) or YieldProcessor() for those who are worried about it. For those who don't know what Sleep(0) on Windows does: It returns the reminder of the current time-slice back to the system is a thread with equal or higher-priority is ready to run. Otherwise it does nothing. GIL flashing is a serious issue if it happens often; with the current event-based GIL on Windows, it never happens (61 cases of GIL flash in 100,000 periodic checks is as good as never). S.M. ___ 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] nonlocal keyword in 2.x?
> From the Django roadmap for supporting 3.0, using 2.6 as a stepping > stone (and if 2.7 was a *better* stepping stone then it would make it > easier): > >http://groups.google.com/group/django-developers/msg/0888b1c8f2518059? Is that still a current plan? It's from November 2008. > This gets us to a situation where, about a year after the release of > Python 3.0, Django will be ready to make the transition -- the only > 2.x Python we'll be supporting is Python 2.6, and 2to3 plus manual > effort and available supporting libraries should make it possible to > also run Django on Python 3.0 either at that point or not long after. > > From there, 2.6 support can be dropped whenever convenient, and Django > can move to running only on Python 3.x at whatever time is judged > appropriate. I would claim that this specific plan was ignoring opportunities for migrating to Python 3.0. My Django port demonstrates that you can very well support 2.3 and 3.0 simultaneously: http://wiki.python.org/moin/PortingDjangoTo3k 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] readonly __doc__
On Fri, 23 Oct 2009 05:39:53 am Brett Cannon wrote: > > Is __doc__ not normal due to its general underscorishness, or is it > > not normal because it isn't? > > I honestly don't follow that sentence. But __doc__ is special because > of its use; documenting how to use of an object. In this case when > you call something like help() on an instance of an object it skips > the instance's value for __doc__ and goes straight to the defining > class and stops there as you don't care how a subclass says to use > itself as that is not what you are working with. Classes don't normally inherit behaviour from their subclasses. Presumably you meant superclass. I expected __doc__ to be just like the other double-underscore objects: lookup skips the instance and goes to the class, then follows the normal rules of inheritance. Consequently I've just discovered that a few of my classes, which I assumed inherited __doc__, don't actually have a docstring. This has consequences beyond help(obj) not working as expected: doctests which I thought were running aren't. Magic behaviour like this is nasty because it breaks the Rule of Least Astonishment. I thought I understood Python's object model and it's rules of inheritance, but not only do double-underscore attributes follow a different rule for inheritance than other attributes, but __doc__ follows a different rule than other double-underscore attributes. -- Steven D'Aprano ___ 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] language summit topic: issue tracker
Another summit, another potential time to see if people want to change anything about the issue tracker. I would bring up: - Dropping Stage in favor of some keywords (e.g. 'needs unit test', 'needs docs') - Adding a freestyle text box to delineate which, if any, stdlib module is the cause of a bug and tie that into Misc/maintainers.rst; would potentially scale back the Component box -Brett ___ 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] language summit topic: issue tracker
Brett Cannon writes: > Another summit, another potential time to see if people want to change > anything about the issue tracker. It requires some coding, but I see OpenID authentication support http://issues.roundup-tracker.org/issue2550523> to be important for lowering the barrier to getting bug reports. -- \“I was once walking through the forest alone and a tree fell | `\ right in front of me, and I didn't hear it.” —Steven Wright | _o__) | 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] nonlocal keyword in 2.x?
On Thu, 22 Oct 2009 12:32:37 -0300, Fabio Zadrozny wrote: > Just as a note, the nonlocal there is not a requirement... > > You can just create a mutable object there and change that object (so, > you don't need to actually rebind the object in the outer scope). > > E.g.: instead of creating a float in the context, create a list with a > single float and change the float in the list (maybe the nonlocal would > be nicer, but it's certainly still usable) Yup, that's what I meant by 'some slightly ugly solutions' in this note: http://mail.scipy.org/pipermail/ipython-dev/2009-September/005529.html in the thread that spawned those notes. nonlocal allows for this pattern to work without the ugliness of writing code like: s = [s] @somedeco def foo(): s[0] += 1 s = s[0] just to be able to 'change s' inside the foo() scope. I felt this was both obvious and ugly enough not to warrant too much explicit mention, but I probably should have left it there for the sake of completeness. Thanks for the feedback. Cheers, f ps - the above shouldn't be taken as either pro or con on the idea of nonlocal in 2.x, just a clarification on why I didn't add the mutable container trick to the original notes. ___ 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
