Re: [Python-Dev] Python Package Management Roadmap in Python Releases

David Lyon writes: > On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote: > > David, you are making a huge leap here thinking that we even want > > a package manager in the stdlib. > > Well - who is 'we'? If it's python-dev people I can accept and > respect that. Yes. The stdlib is a

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

On approximately 10/21/2009 7:13 PM, came the following characters from the keyboard of David Lyon: On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote: We make a language here. Distutils exists as a bootstrap mechanism for the package story and for our own building needs of the stdlib.

Re: [Python-Dev] time.clock() on windows

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

Re: [Python-Dev] nonlocal keyword in 2.x?

On Wed, Oct 21, 2009 at 6: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

Re: [Python-Dev] time.clock() on windows

On 22/10/2009 8:52 AM, Scott Dial wrote: Curt Hagenlocher wrote: 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. Some SVN detective work takes this to all the way ba

Re: [Python-Dev] GIL behaviour under Windows

Sturla Molden skrev: However, David Beazley is not talking about Windows. Since the GIL is apparently not a mutex on Windows, it could behave differently. So I wrote a small script that contructs a GIL battle, and record how often a check-interval results in a thread-switch or not. For monito

Re: [Python-Dev] GIL behaviour under Windows

Antoine Pitrou skrev: Kristján sent me a patch which I applied and is supposed to fix this. Anyway, thanks for the numbers. The GIL does seem to fare a bit better (zero latency with the Pi calculation in the background) than under Linux, although it may be caused by the limited resolution of time

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote: > But that assumes you can get your tool into the stdlib. No I'm not assuming that I can. I am actually assuming that I cannot.. So lets move forward.. > It would have been > better to phrase the question as "is there interest in having a

[Python-Dev] nonlocal keyword in 2.x?

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

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

On Wed, Oct 21, 2009 at 18:17, David Lyon wrote: > On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon wrote: > > > but I don't see why python-dev should have input on that sort of thing. > > python-dev is the only place where we could get a change to the > installation > binary release. We'd need

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon wrote: > but I don't see why python-dev should have input on that sort of thing. python-dev is the only place where we could get a change to the installation binary release. We'd need a change and the addition of a program shortcut. > If you want

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

On Wed, Oct 21, 2009 at 17:34, David Lyon wrote: > > Hi All, > > I started out some time ago and wrote a Python Package Manager > with wxpython. It was an interesting learning experience for > me. I was new to python. > > Some have pointed out that using wx was not a good idea for > a tool to go

Re: [Python-Dev] PEP 384

On Wed, Oct 21, 2009 at 17:44, Andrew Svetlov wrote: > Is there some public branch for this PEP? > I like the idea and glad to look on implementation. > Thanks. > If there was such a thing the PEP would mention it. But since the PEP is about not changing ABIs between releases I don't see why some

[Python-Dev] PEP 384

Is there some public branch for this PEP? I like the idea and glad to look on implementation. Thanks. ___ 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] Python Package Management Roadmap in Python Releases

Hi All, I started out some time ago and wrote a Python Package Manager with wxpython. It was an interesting learning experience for me. I was new to python. Some have pointed out that using wx was not a good idea for a tool to go into all the python distributions. Because it required the externa

Re: [Python-Dev] Python 2.6.4rc2

On Oct 21, 2009, at 7:00 PM, Zooko O'Whielacronx wrote: Do you know anything about this alleged regression in 2.6.3 with regard to the __doc__ property? https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 This is the first I've heard of it, but my guess is that it's caused

Re: [Python-Dev] time.clock() on windows

> 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

Re: [Python-Dev] Python 2.6.4rc2

Barry: Do you know anything about this alleged regression in 2.6.3 with regard to the __doc__ property? https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 Regards, Zooko ___ Python-Dev mailing list Python-Dev@python.org http://mail.p

Re: [Python-Dev] time.clock() on windows

Curt Hagenlocher wrote: > 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. Some SVN detective work takes this to all the way back to r7713 (1997-04-02). The origina

Re: [Python-Dev] time.clock() on windows

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())

Re: [Python-Dev] time.clock() on windows

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 ind

[Python-Dev] time.clock() on windows

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 diff

[Python-Dev] Proposal: Moratorium on Python language changes

In the python-ideas list I've proposed a moratorium on language changes. It seems to be gaining momentum; if you want to have a say, come over. You can watch the discussion in the archives starting here: http://mail.python.org/pipermail/python-ideas/2009-October/006305.html . (Eventually I'll move

Re: [Python-Dev] GIL behaviour under Windows

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: > Le mercredi 21 octobre 2009 à 12:42 -0500, John Arbash Meinel a écrit : >> You can use time.clock() instead to get <15ms resolution. Changing all >> instances of 'time.time' to 'time.clock' gives me this result: > [snip] >> ---

Re: [Python-Dev] GIL behaviour under Windows

Le mercredi 21 octobre 2009 à 12:42 -0500, John Arbash Meinel a écrit : > > You can use time.clock() instead to get <15ms resolution. Changing all > instances of 'time.time' to 'time.clock' gives me this result: [snip] > > --- Latency --- > > Background CPU task: Pi calculation (Python) > > CPU

Re: [Python-Dev] GIL behaviour under Windows

Antoine Pitrou wrote: > Sturla Molden molden.no> writes: >> It does not crash the interpreter, but it seems it can deadlock. > > Kristján sent me a patch which I applied and is supposed to fix this. > Anyway, thanks for the numbers. The GIL does seem to fare a bit better (zero > latency with the

Re: [Python-Dev] Interest in integrating C decimal module into Python?

Mark Dickinson schrieb: > * There's a partially complete rewrite of decimal in C in the sandbox, > dating from the Need for Speed sprint in 2006: > > http://svn.python.org/view/sandbox/trunk/decimal-c/ > > Last time I looked at this it wasn't up to date with the decimal > specification: I'm not

Re: [Python-Dev] GIL behaviour under Windows

Sturla Molden molden.no> writes: > > It does not crash the interpreter, but it seems it can deadlock. Kristján sent me a patch which I applied and is supposed to fix this. Anyway, thanks for the numbers. The GIL does seem to fare a bit better (zero latency with the Pi calculation in the backgro

Re: [Python-Dev] GIL behaviour under Windows

Sturla Molden skrev: does not crash the interpreter, but it seems it can deadlock. Here is what I get con a quadcore (Vista, Python 2.6.3). This what I get with affinity set to CPU 3. There are deadlocks happening at random locations in ccbench.py. It gets worse with affinity set to one pr

Re: [Python-Dev] GIL behaviour under Windows

Antoine Pitrou skrev: (*) http://svn.python.org/view/sandbox/trunk/ccbench/ I´ve run it twice on my dual core machine. It hangs every time, but not in the same place: D:\pydev\python\trunk\PCbuild>python.exe \tmp\ccbench.py Ah, you should report a bug then. ccbench is pure Python

Re: [Python-Dev] Interest in integrating C decimal module into Python?

On Wed, Oct 21, 2009 at 4:05 PM, Antoine Pitrou wrote: > Mark Dickinson gmail.com> writes: >> BTW, does anyone know the current SLOC count for py3k? > > Here you are, generated using David A. Wheeler's 'SLOCCount': > [...] Thanks, Antoine! With SLOCCount I can revise my earlier numbers, as well

Re: [Python-Dev] [Python-ideas] Remove GIL with CAS instructions?

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

Re: [Python-Dev] GIL behaviour under Windows

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: >> I don't really know how this test works, so I won't claim to understand >> the results either. However, here you go: > > Thanks. > > Interesting results. I wonder what they would be like on a multi-core > machine. The GIL see

Re: [Python-Dev] Interest in integrating C decimal module i nto Python?

Mark Dickinson gmail.com> writes: > > There are certainly some open issues (e.g., what to do with > the existing Python module; what should other Python implementations > do). The existing module could be kept as a fallback. Also, the test suite should be careful to test both implementations (l

Re: [Python-Dev] Interest in integrating C decimal module into Python?

On Wed, Oct 21, 2009 at 11:37 AM, Nick Coghlan wrote: > As far as decimal.py in particular goes, there are significant > maintenance gains in keeping a lot of the non-performance critical > context management code in pure Python. So we're likely to wait and see > how much speed Mark can wring out

Re: [Python-Dev] Interest in integrating C decimal module into Python?

On Tue, Oct 20, 2009 at 2:15 PM, Stefan Krah wrote: > 1. Are you generally in favour of a C decimal module in Python? I'm certainly interested in the general idea; whether I'd be in favour of replacing decimal.py with a particular C version would depend on a lot of factors, with code quality, in

Re: [Python-Dev] GIL behaviour under Windows

> > (*) http://svn.python.org/view/sandbox/trunk/ccbench/ > > I´ve run it twice on my dual core machine. It hangs every time, but not in > the same place: > D:\pydev\python\trunk\PCbuild>python.exe \tmp\ccbench.py Ah, you should report a bug then. ccbench is pure Python (and not particularly e

Re: [Python-Dev] GIL behaviour under Windows

> -Original Message- > Could you try ccbench (*) under Windows? The only Windows system I have > here is > a qemu virtual machine and it wouldn't be very realistic to do > concurrency > measurements on it. > > (*) http://svn.python.org/view/sandbox/trunk/ccbench/ I´ve run it twice on my

Re: [Python-Dev] GIL behaviour under Windows

> -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of Antoine Pitrou > Sent: 21. október 2009 10:52 > To: python-dev@python.org > Subject: Re: [Python-Dev] GIL behaviour under Windows

Re: [Python-Dev] GIL behaviour under Windows

Antoine Pitrou wrote: > Interesting results. I wonder what they would be like on a multi-core > machine. The GIL seems to behave perfectly on your setup (no performance > degradation due to concurrency, and zero latencies). You are correct, my machine is a single-core system. I don't have any mult

Re: [Python-Dev] GIL behaviour under Windows

> I don't really know how this test works, so I won't claim to understand > the results either. However, here you go: Thanks. Interesting results. I wonder what they would be like on a multi-core machine. The GIL seems to behave perfectly on your setup (no performance degradation due to concurren

Re: [Python-Dev] GIL behaviour under Windows

Antoine Pitrou wrote: > Could you try ccbench (*) under Windows? The only Windows system I have here > is > a qemu virtual machine and it wouldn't be very realistic to do concurrency > measurements on it. > > (*) http://svn.python.org/view/sandbox/trunk/ccbench/ > I don't really know how this t

Re: [Python-Dev] GIL behaviour under Windows

Hello Kristjan, > This depends entirely on the platform and primitives used to implement the > GIL. > I'm interested in windows. Could you try ccbench (*) under Windows? The only Windows system I have here is a qemu virtual machine and it wouldn't be very realistic to do concurrency measurement

Re: [Python-Dev] Interest in integrating C decimal module into Python?

Maciej Fijalkowski wrote: > For example other python implementations might decide to use python > version as long as builtin version does not appear. Python versions are > usually also better targets for jit than mixed versions. C level versions also > usually have more bugs (just statistics), so s

Re: [Python-Dev] SIGCHECK() in longobject.c

Brett Cannon wrote: > On Tue, Oct 20, 2009 at 07:57, Mark Dickinson > wrote: > The Deccoeff type is very simple, though. It would be easy to create > a pure Python version of it, and then do something like: > > try: >from _decimal import Deccoeff #

Re: [Python-Dev] [Python-ideas] Remove GIL with CAS instructions?

> -Original Message- > From: python-ideas-bounces+kristjan=ccpgames@python.org > [mailto:python-ideas-bounces+kristjan=ccpgames@python.org] On > Behalf Of Sturla Molden > Sent: 20. október 2009 22:13 > To: python-id...@python.org > Subject: Re: [Python-ideas] Remove GIL with CAS i