On Oct 14, 7:32 pm, alex23 wrote:
> You can do this right now with Python 3.2+ and concurrent.futures:
>
> from concurrent.futures import ThreadPoolExecutor
You may have finally sold me on struggling through the upgrade from
Python 2.6! I've been doing reasonably well with the Multiprocessing
m
On Friday, October 14, 2011 6:23:15 PM UTC-7, alex23 wrote:
> On Oct 14, 4:56 pm, Carl Banks
> wrote:
> > But you can see that, fully realized, syntax like that can do much more
> > than can be done with library code.
>
> Well sure, but imaginary syntax can do _anything_. That doesn't mean
> it'
On 2011-10-14, Westley Mart?nez wrote:
> On Thu, Oct 13, 2011 at 11:56:20PM -0700, Carl Banks wrote:
>
> While we're at it, let's throw in the register keyword.
Yah! C compilers have been ignoring it for ages, and I miss it.
--
Grant
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, Oct 15, 2011 at 1:15 PM, Chris Rebert wrote:
> On Fri, Oct 14, 2011 at 6:23 PM, alex23 wrote:
>> Well sure, but imaginary syntax can do _anything_. That doesn't mean
>> it's possible within CPython.
>
> But it's The Future now! Where are my jetpack and `dwim` statement,
> dammit?! :-)
I
On Oct 15, 12:32 pm, alex23 wrote:
> from functools import partial
You can ignore this, sorry, leftover from earlier code :)
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 13, 10:35 pm, "Martin P. Hellwig"
wrote:
> def do_something():
> a = 4
> b = 2
> c = 1
> ooo:
> a += 1
> b += 2
> c += 3
> print(a, b, c)
>
> What I would expect to happen that all statements within the ooo block
> may be executed out
> of
On Fri, Oct 14, 2011 at 6:23 PM, alex23 wrote:
> On Oct 14, 4:56 pm, Carl Banks wrote:
>> But you can see that, fully realized, syntax like that can do much more
>> than can be done with library code.
>
> Well sure, but imaginary syntax can do _anything_. That doesn't mean
> it's possible within
alex23 writes:
> On Oct 14, 4:56 pm, Carl Banks wrote:
> > But you can see that, fully realized, syntax like that can do much more
> > than can be done with library code.
>
> Well sure, but imaginary syntax can do _anything_. That doesn't mean
> it's possible within CPython.
+1 QotW
--
\
On Oct 14, 4:56 pm, Carl Banks wrote:
> But you can see that, fully realized, syntax like that can do much more
> than can be done with library code.
Well sure, but imaginary syntax can do _anything_. That doesn't mean
it's possible within CPython.
--
http://mail.python.org/mailman/listinfo/pyt
On Thu, Oct 13, 2011 at 11:56:20PM -0700, Carl Banks wrote:
> On Thursday, October 13, 2011 7:16:37 PM UTC-7, Steven D'Aprano wrote:
> > > What I would expect to happen that all statements within the ooo block
> > > may be executed out
> > > of order. The block itself waits till all statements are
Carl Banks wrote:
> On Thursday, October 13, 2011 7:16:37 PM UTC-7, Steven D'Aprano wrote:
>> > What I would expect to happen that all statements within the ooo block
>> > may be executed out
>> > of order. The block itself waits till all statements are returned
>> > before continuing.
>>
>> Why
On Thursday, October 13, 2011 5:35:30 AM UTC-7, Martin P. Hellwig wrote:
> What I would expect to happen that all statements within the ooo block
> may be executed out
> of order. The block itself waits till all statements are returned before
> continuing.
>
> What do you think?
The statement i
On Thursday, October 13, 2011 7:16:37 PM UTC-7, Steven D'Aprano wrote:
> > What I would expect to happen that all statements within the ooo block
> > may be executed out
> > of order. The block itself waits till all statements are returned before
> > continuing.
>
> Why do you think this needs to
Martin P. Hellwig wrote:
> I was wondering if there could be an advantage to add another control
> flow statement.
> For the purpose of this writing let's say "ooo" which stands for 'out of
> order'.
[...]
> What I would expect to happen that all statements within the ooo block
> may be executed o
jkn:
> FWIW, this looks rather like the 'PAR' construct of Occam to me.
>
> http://en.wikipedia.org/wiki/Occam_%28programming_language%29
Earlier than that, 'par' is from Algol 68:
http://en.wikipedia.org/wiki/ALGOL_68#par:_Parallel_processing
Neil
--
http://mail.python.org/mailman/listi
On Thu, 13 Oct 2011 15:33:27 +0100, jkn wrote:
FWIW, this looks rather like the 'PAR' construct of Occam to me.
http://en.wikipedia.org/wiki/Occam_%28programming_language%29
I was going to say the same thing. Occam's answer to Stefan's
question about what to do if you want more than one sta
On 13/10/2011 15:13, Stefan Behnel wrote:
Martin P. Hellwig, 13.10.2011 14:35:
I was wondering if there could be an advantage to add another control
flow
statement.
Changes at that level must be very well justified, are often rejected
for the reason of being not too complicated to write in som
FWIW, this looks rather like the 'PAR' construct of Occam to me.
http://en.wikipedia.org/wiki/Occam_%28programming_language%29
J^n
--
http://mail.python.org/mailman/listinfo/python-list
Martin P. Hellwig, 13.10.2011 14:35:
I was wondering if there could be an advantage to add another control flow
statement.
Changes at that level must be very well justified, are often rejected for
the reason of being not too complicated to write in some other form and are
close to impossible
On Thu, Oct 13, 2011 at 11:35 PM, Martin P. Hellwig
wrote:
> What I would expect to happen that all statements within the ooo block may
> be executed out
> of order. The block itself waits till all statements are returned before
> continuing.
>
In a statically-typed language such as C, this can b
First of all let me say that I have no authority or knowledge of
language design or multi-processing except from a user point of view,
having a decade or so experience.
I would like your opinion and appreciate any feedback and value any
hints to documentation, procedures or related ramblings :-)
21 matches
Mail list logo
