On Mon, May 17, 2010 at 15:05, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 17 May 2010 14:47:25 +0200
Lennart Regebro rege...@gmail.com wrote:
On Mon, May 17, 2010 at 14:12, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 17 May 2010 08:28:08 +0200
Lennart Regebro rege...@gmail.com
On Tue, 18 May 2010 08:45:41 +0200
Lennart Regebro rege...@gmail.com wrote:
Are you referring to the New GIL?
Yes.
At has been shown, it also in certain cases will race with the OS
scheduler, so this is not already fixed, although apparently improved,
if I understand correctly.
Race
Nir Aides wrote:
I would like to restart this thread with 2 notes from the lively discussion:
a) Issue 7946 (and this discussion?) concerns Python 3.2
b) The GIL problems are not specific to OSX. The old and new GIL
misbehave on GNU/Linux and Windows too.
I think Antoine and Bill went off
Bill Janssen, 17.05.2010 23:09:
Most folks don't use threads
Seems like a somewhat reasonable assumption to me.
they use a higher-level abstraction like the nltk library.
I have my doubts that this applies to most folks - likely not even to
most of those who use threads.
Stefan
On Tue, May 18, 2010 at 12:53, Antoine Pitrou solip...@pitrou.net wrote:
Race is a strange term here and I'm not sure what you mean.
The issue found out by Dave Beazley can't be reasonably described by
this word, I think.
OK, maybe race is the wrong word. But that doesn't mean the issue
Le mardi 18 mai 2010 à 14:16 +0200, Lennart Regebro a écrit :
Please read and understand the issue report mentioned by Nir before
trying to make statements based on rumours heard here and there.
Oh, so Dave Beazleys reports is a rumour now.
Your and other people's grandiloquent
On Tue, May 18, 2010 at 14:52, Antoine Pitrou solip...@pitrou.net wrote:
Le mardi 18 mai 2010 à 14:16 +0200, Lennart Regebro a écrit :
Please read and understand the issue report mentioned by Nir before
trying to make statements based on rumours heard here and there.
Oh, so Dave Beazleys
Lennart Regebro wrote:
On Tue, May 18, 2010 at 14:52, Antoine Pitrou solip...@pitrou.net wrote:
Le mardi 18 mai 2010 à 14:16 +0200, Lennart Regebro a écrit :
Please read and understand the issue report mentioned by Nir before
trying to make statements based on rumours heard here and there.
On Tue, May 18, 2010 at 3:43 PM, Martin v. Löwis mar...@v.loewis.de wrote:
So please join us in considering the issue fixed unless you can provide
a really world example that demonstrates the contrary.
The server software I maintain (openrpg) experiences this issue with
when I tried porting the
On Sun, May 16, 2010 at 1:07 PM, Nir Aides n...@winpdb.org wrote:
Relevant Python issue: http://bugs.python.org/issue7946
Is there any chance Antoine's gilinter patch from that issue might
be applied to python 2.7? I have been experiencing rare long delays
in simple io operations in
On Tue, 18 May 2010 14:39:43 -0700
Mike Klaas mike.kl...@gmail.com wrote:
On Sun, May 16, 2010 at 1:07 PM, Nir Aides n...@winpdb.org wrote:
Relevant Python issue: http://bugs.python.org/issue7946
Is there any chance Antoine's gilinter patch from that issue might
be applied to python 2.7?
I just wanted to let the python-dev community know about some tracks we had at
the recently concluded Ubuntu Developer Summit in Brussels. Among the several
Python-related discussions, we talked about what versions of Python will be
supported and default in the next version of Ubuntu (10.10, code
Hello, everyone.
I've checked the new collections.Counter class and I think I've found a bug:
from collections import Counter
c1 = Counter([1, 2, 1, 3, 2])
c2 = Counter([1, 1, 2, 2, 3])
c3 = Counter([1, 1, 2, 3])
c1 == c2 and c3 not in (c1, c2)
True
# Perfect, so far. But... There's
Hello, everybody.
I've been searching for a data structure like a tuple/list *but* unordered --
like a set, but duplicated elements shouldn't be removed. I have not even
found a recipe, so I'd like to write an implementation and contribute it to
the collections module in the standard library.
On Tue, 18 May 2010 21:43:30 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I can understand why Antoine is being offended: it's his implementation
that you attacked. You literally said At has been shown, it also in
certain cases will race with the OS scheduler, so this is not already
This is typically called a bag. Maybe searching for that will help
you find a recipe?
On Tue, May 18, 2010 at 3:13 PM, Gustavo Narea m...@gustavonarea.net wrote:
Hello, everybody.
I've been searching for a data structure like a tuple/list *but* unordered --
like a set, but duplicated elements
2010/5/18 Guido van Rossum gu...@python.org:
This is typically called a bag. Maybe searching for that will help
you find a recipe?
Yes, and we have one in Python 2.7+ called collections.Counter.
--
Regards,
Benjamin
___
Python-Dev mailing list
On Wed, 19 May 2010 08:13:42 am Gustavo Narea wrote:
Hello, everybody.
I've been searching for a data structure like a tuple/list *but*
unordered -- like a set, but duplicated elements shouldn't be
removed. I have not even found a recipe, so I'd like to write an
implementation and contribute
On Tue, May 18, 2010 at 11:13:42PM +0100, Gustavo Narea wrote:
To sum up, it would behave like a tuple or a list, except when it's compared
with another object: They would be equivalent if they're both unordered
tuples/lists, and have the same elements. There can be mutable and immutable
Gustavo Narea m...@gustavonarea.net writes:
I've been searching for a data structure like a tuple/list *but*
unordered -- like a set, but duplicated elements shouldn't be removed.
By that description, you're looking for the “Bag” pattern.
[…]
A multiset is not exactly what I need: I still
On Tue, May 18, 2010 at 2:50 PM, Antoine Pitrou solip...@pitrou.net wrote:
There's no chance for this since the patch relies on the new GIL.
(that's unless there's a rush to backport the new GIL in 2.7, of course)
Thanks I missed that detail.
I think your rare long delays might be related to
Antoine,
This is a pretty good summary that mirrors my thoughts on the GIL matter as
well. In the big picture, I do think it's desirable for Python to address the
multicore performance issue--namely to not have the performance needlessly
thrashed in that environment. The original new GIL
On Tue, 18 May 2010 17:26:44 -0700
Mike Klaas mike.kl...@gmail.com wrote:
I think your rare long delays might be related to the old GIL's own
problems, though. How long are they?
Typically between 20 and 60s.
You mean milliseconds I suppose?
If it's the case, then you may simply be
On 19/05/10 10:35, David Beazley wrote:
Antoine,
This is a pretty good summary that mirrors my thoughts on the GIL
matter as well. In the big picture, I do think it's desirable for
Python to address the multicore performance issue--namely to not have
the performance needlessly thrashed in
24 matches
Mail list logo
