On Mon, Oct 26, 2009 at 15:59, Steven D'Aprano wrote:
> On Tue, 27 Oct 2009 08:54:52 am Nick Coghlan wrote:
> > Raymond Hettinger wrote:
> > > [GvR]
> > >
> > >> I still wish we could go back in time and unify sets and dicts, if
> > >> only to find out how that experiment would turn out.
> > >
>
On 26Oct2009 22:45, exar...@twistedmatrix.com wrote:
| On 04:18 pm, dan...@stutzbachenterprises.com wrote:
| >On Mon, Oct 26, 2009 at 10:58 AM, Antoine Pitrou write:
| >Do we really need priority requests at all? They seem counter to your
| >desire for simplicity and allowing the operating system
On Oct 26, 2009, at 6:45 PM, exar...@twistedmatrix.com wrote:
Despite what I said above, however, I would also take a default
position against adding any kind of more advanced scheduling system
here. It would, perhaps, make sense to expose the APIs for
controlling the platform scheduler, t
On Tue, 27 Oct 2009 10:09:14 am Guido van Rossum wrote:
> On Mon, Oct 26, 2009 at 4:06 PM, Antoine Pitrou
wrote:
> > Steven D'Aprano pearwood.info> writes:
> >> I don't understand that rationale. Let's take a concrete example.
> >> The new `yield from` syntax was accepted
> >
> > Was it?
>
> No.
On Mon, Oct 26, 2009 at 4:06 PM, Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
>>
>> I don't understand that rationale. Let's take a concrete example. The
>> new `yield from` syntax was accepted
>
> Was it?
No.
--
--Guido van Rossum
PS. My elbow needs a couple more weeks of r
Steven D'Aprano pearwood.info> writes:
>
> I don't understand that rationale. Let's take a concrete example. The
> new `yield from` syntax was accepted
Was it?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On Tue, 27 Oct 2009 08:54:52 am Nick Coghlan wrote:
> Raymond Hettinger wrote:
> > [GvR]
> >
> >> I still wish we could go back in time and unify sets and dicts, if
> >> only to find out how that experiment would turn out.
> >
> > I'm curious about the outcome of another experiment along those
> >
On behalf of the Python community, I'm happy to announce the
availability of Python 2.6.4. This is the latest production-ready
version in the Python 2.6 series.
We had a little trouble with the Python 2.6.3 release; a number of
unfortunate regressions were introduced. I take responsibilit
On 04:18 pm, dan...@stutzbachenterprises.com wrote:
On Mon, Oct 26, 2009 at 10:58 AM, Antoine Pitrou
wrote:
Er, I prefer to keep things simple. If you have lots of I/O you should
probably
use an event loop rather than separate threads.
On Windows, sometimes using a single-threaded event loop i
Raymond Hettinger wrote:
> [GvR]
>> I still wish we could go back in time and unify sets and dicts, if
>> only to find out how that experiment would turn out.
>
> I'm curious about the outcome of another experiment along those lines.
> Is anyone seeing uptake for the set methods on mapping views i
Terry Reedy wrote:
> Alexander Belopolsky wrote:
>> Terry Reedy wrote:
>>> I had exactly the same idea, but did not post because it violates the
>>> general rule that mutators return None.
>>
>> Is there such a rule? What about set/dict pop?
>
> The rule perhaps should be restated as 'Collection
On Mon, Oct 26, 2009 at 2:43 PM, Antoine Pitrou wrote:
> Collin Winter gmail.com> writes:
> [the Dave Beazley benchmark]
>> The results below are benchmarking py3k as the control, newgil as the
>> experiment. When it says "x% faster", that is a measure of newgil's
>> performance over py3k's.
>>
>
Collin Winter gmail.com> writes:
>
> My results for an 2.4 GHz Intel Core 2 Duo MacBook Pro (OS X 10.5.8):
Thanks!
[the Dave Beazley benchmark]
> The results below are benchmarking py3k as the control, newgil as the
> experiment. When it says "x% faster", that is a measure of newgil's
> perfor
For those of you who want to tinker with it, I posted the patch against the
current trunk at http://bugs.python.org/issue7212
Have fun,
wr
Am Montag, 26. Oktober 2009 21:32:32 schrieb Guido van Rossum:
> On Mon, Oct 26, 2009 at 1:19 PM, Antoine Pitrou wrote:
> > Jesse Noller gmail.com> writes:
On Mon, Oct 26, 2009 at 1:19 PM, Antoine Pitrou wrote:
> Jesse Noller gmail.com> writes:
>>
>> So far, fiddling with the PEP, I'm on the fence - adding a method to a
>> built-in object type is sort of a grey area (at least in my mind). It
>> depends on if doing so significantly alters the languag
On Mon, Oct 26, 2009 at 7:56 PM, Guido van Rossum wrote:
> I'm beginning to think maybe adding a method to a built-in object type
> *should* fall under the moratorium.
Another possible test case for this decision is the int.from_bytes and
int.to_bytes methods, proposed a while ago, and implemente
I'm curious about the outcome of another experiment along those lines.
Is anyone seeing uptake for the set methods on mapping views in Py3.x?
Next version of Graphine will use them heavily for graph
merges and set operations on graphs.
That's great! Thanks for the data point.
I look forwar
Jesse Noller gmail.com> writes:
>
> So far, fiddling with the PEP, I'm on the fence - adding a method to a
> built-in object type is sort of a grey area (at least in my mind). It
> depends on if doing so significantly alters the language/syntax.
We have recently added things like float.fromhex()
On Mon, Oct 26, 2009 at 3:56 PM, Guido van Rossum wrote:
> On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger wrote:
>> P.S. It is weird that this thread is gaining traction at the same
>> time as the moratorium thread. Go figure :-)
>
> I'm beginning to think maybe adding a method to a built-
On Mon, Oct 26, 2009 at 3:56 PM, Raymond Hettinger wrote:
> [GvR]
>>
>> I still wish we could go back in time and unify sets and dicts, if
>> only to find out how that experiment would turn out.
>
> I'm curious about the outcome of another experiment along those lines.
> Is anyone seeing uptake fo
On Mon, Oct 26, 2009 at 3:56 PM, Guido van Rossum wrote:
> On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger wrote:
>> P.S. It is weird that this thread is gaining traction at the same
>> time as the moratorium thread. Go figure :-)
>
> I'm beginning to think maybe adding a method to a built-
On Sun, Oct 25, 2009 at 1:22 PM, Antoine Pitrou wrote:
> Having other people test it would be fine. Even better if you have an
> actual multi-threaded py3k application. But ccbench results for other
> OSes would be nice too :-)
My results for an 2.4 GHz Intel Core 2 Duo MacBook Pro (OS X 10.5.8):
[GvR]
I still wish we could go back in time and unify sets and dicts, if
only to find out how that experiment would turn out.
I'm curious about the outcome of another experiment along those lines.
Is anyone seeing uptake for the set methods on mapping views in Py3.x?
I haven't seen any code us
On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger wrote:
> P.S. It is weird that this thread is gaining traction at the same
> time as the moratorium thread. Go figure :-)
I'm beginning to think maybe adding a method to a built-in object type
*should* fall under the moratorium.
--
--Guido v
Chris Bergstresser]
I like the proposed set.get() method, personally.
Sets have been implemented in many languages, but I've only
seen one that implemented this functionality (the "arb" function
in SETL). For the most part, it seems that this is an uncommon need.
Also consider that th
Alexander Belopolsky wrote:
Changing the subject to reflect branched discussion and forwarding to
python-ideas where it probably belongs.
On Mon, Oct 26, 2009 at 12:02 PM, Terry Reedy wrote:
Alexander Belopolsky wrote:
Here is an alternative idea on how storing interned objects in a set
can
On Mon, Oct 26, 2009 at 11:38 AM, Guido van Rossum wrote:
> - If sets were to grow an API to non-destructively access the object
> stored in the set for a particular key, then dicts should have such a
> method too.
>
> - Ditto for an API to non-destructively get an arbitrary element.
>
> - I'm far
Daniel Stutzbach stutzbachenterprises.com> writes:
>
> Do we really need priority requests at all? They seem counter to your
> desire for simplicity and allowing the operating system's scheduler to do
> its work.
No, they can be disabled (removed) if we prefer. With priority requests
disabled,
Changing the subject to reflect branched discussion and forwarding to
python-ideas where it probably belongs.
On Mon, Oct 26, 2009 at 12:02 PM, Terry Reedy wrote:
> Alexander Belopolsky wrote:
>
>> Here is an alternative idea on how storing interned objects in a set
>> can be supported. Currentl
All this talk of equivalence classes makes me dizzy. :-)
- If sets were to grow an API to non-destructively access the object
stored in the set for a particular key, then dicts should have such a
method too.
- Ditto for an API to non-destructively get an arbitrary element.
- I'm far from convinc
On Mon, Oct 26, 2009 at 10:58 AM, Antoine Pitrou wrote:
> Er, I prefer to keep things simple. If you have lots of I/O you should
> probably
> use an event loop rather than separate threads.
>
On Windows, sometimes using a single-threaded event loop is sometimes
impossible. WaitForMultipleObjects
Alexander Belopolsky wrote:
Here is an alternative idea on how storing interned objects in a set
can be supported. Currently set.add method returns None and had no
effect when set already has an object equal to the one being added. I
propose to consider changing that behavior to make set.add r
Sturla Molden molden.no> writes:
>
> Antoine Pitrou skrev:
> > - priority requests, which is an option for a thread requesting the GIL
> > to be scheduled as soon as possible, and forcibly (rather than any other
> > threads). T
> Should a priority request for the GIL take a priority number?
Er,
Antoine Pitrou skrev:
- priority requests, which is an option for a thread requesting the GIL
to be scheduled as soon as possible, and forcibly (rather than any other
threads). T
Should a priority request for the GIL take a priority number?
- If two threads make a priority requests for the GIL,
On Sun, Oct 25, 2009 at 1:48 AM, Nick Coghlan wrote:
> Terry Reedy wrote:
>>> In this model, a
>>> get() method, or even a __getitem__ with s[k] is k, is only natural.
>>
>> No, if key and value were the same thing, the get method would be
>> nonesense, as Guido said. But since they are not, sinc
On Oct 26, 2009, at 10:09 AM, Kristján Valur Jónsson wrote:
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On
Behalf
Of Sturla Molden
time.sleep should generate a priority request to re-acqu
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Sturla Molden
> time.sleep should generate a priority request to re-acquire the GIL;
> and
> so should all other blocking standard
Antoine Pitrou skrev:
- priority requests, which is an option for a thread requesting the GIL
to be scheduled as soon as possible, and forcibly (rather than any other
threads).
So Python threads become preemptive rather than cooperative? That would
be great. :-)
time.sleep should generate a p
Brett Cannon wrote:
It's up to Andrew to get the support in. While I have faith he will,
this is why we have been scaling back the support for alternative OSs
for a while and will continue to do so. I suspect the day Andrew stops
keeping up will be the day we push to have OS/2 be externally mai
On Saturday 24 October 2009, Christian Heimes wrote:
> Antoine Pitrou wrote:
> > * The unused file: thread_wince.h
> >
> > Windows CE has actually been using thread_nt.h since January 2009 (see
> > http://bugs.python.org/issue4893 ). thread_wince.h is still there, but
> > it's unused and grep bring
Terry Reedy udel.edu> writes:
>
> I am curious as to whether the entire mechanism is or can be turned off
> when not needed -- when there are not threads (other than the main,
> starting thread)?
It is an implicit feature: when no thread is waiting on the GIL, the GIL-holding
thread isn't noti
>>> This sounds like something that should be reported
>>> upstream. Particularly if you know how to reproduce it. Has it been?
>>
>> No, largely because I can't reproduce it at all. It's happened maybe
>> 4-5 times in the past 2 years or so. All that I see is that my end
>> looks good yet the m
David Bolen wrote:
> MRAB writes:
>
>> Couldn't you write a script to check the status periodically?
>
> Sure, I suppose scraping the web status page would work. If it
> happened frequently I'd probably be forced to do something like that,
> but it's relatively low frequency (though I guess it
Hi,
I totally agree regarding the efficiency. Code that relies on a fast "non-
removing .pop()" probably has other worse bottlenecks that should be targetted
first.
This would, however, relief every programmer who needs this the first time in
his Python experience, to research how this could be
> Why not allow that?
>
> def any(self, predicate=lambda x: True, default=None)
> for a in self:
> if predicate(a):
> break
> else:
> return default
> return a
I'm +0 (given that I'm still skeptical about the need to have somethi
"Martin v. Löwis" writes:
> > res.get() would be a fairly obvious way to do it. Enough that I would
> > probably never have gone searching for any of the other answers. Though
> > personally, I think I would call it "set.peek()", but the specific name
> > doesn't really matter to me.
>
> So
[John Arbash Meine]
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
The first version uses direct calls for the for-loop opcodes.
The other two have to do functions/method look-up and
make a pure python function call (neither is very fast).
FW
47 matches
Mail list logo
