Agreed it is not a PEP yet. Hence the word "Exploration" in front of it. This ia domain which needs some discussions before developing a good PEP. May be I should call it a PEPlet ;o) Cheers <k/> Guido van Rossum wrote: > On 9/18/07, Krishna Sankar <[EMAIL PROTECTED]> wrote: > >> The vagueness is deliberate, to keep the options open until we have >> some form o convergence. Parallelism/concurrency is a vast and important >> domain that I do not want to develop a hasty proposal. But I did want to >> start thinking in terms of concrete proposals, not pontifying, hence the >> "pragmatic" section. >> > > As long as it's this vague it doesn't deserve to be called a PEP > though. PEPs can't be vague, they must make specific proposals. As > long as this is intentionally half-baked it belongs back in > python-ideas and there's no point in pretending to be writing a "PEP". > > >> Happy to hear that you are open to PVM changes. It will not be asked >> unless and until we all are crisp about it. >> Cheers >> <k/> >> >> Guido van Rossum wrote: >> >>> On 9/18/07, Krishna Sankar <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Folks, >>>> As a follow-up to the py3k discussions started by Bruce and Guido, I >>>> pinged Brett and he suggested I submit an exploratory proposal. Would >>>> appreciate insights, wisdom, the good, the bad and the ugly. >>>> >>>> A) Does it make sense ? >>>> B) Which application sets should we consider in designing the >>>> interfaces and implementations >>>> C) In this proposal, parallelism and concurrency are used in an >>>> interchangeable fashion. Thoughts ? >>>> D) Please suggest pertinent links, discussions and insights. >>>> E) I have kept the proposal to a minimum to start the discussions and >>>> to explore if this is the right thing to do. Collaboratively, as we >>>> zero-in on one or two approaches, the idea is to expand it to a crisp >>>> and clear PEP. Need to do some more formatting as well. >>>> >>>> >>> I'd say it is a little light on specific proposals. The only section >>> that actually proposes anything is this: >>> >>> >>> >>>> Pragmatic proposal >>>> ------------------ >>>> May I suggest we embed two primitives in Python 3K: >>>> A) A functional style share-nothing set of interfaces (and >>>> implementations thereof) - provides the task parallelism/concurrency >>>> capability, "small messages, big computations" as Joe Armstrong calls it[3] >>>> B) A limited shared memory based model for data intensive parallelism >>>> >>>> Most probably this would be part of stdlib. While Guido is almost right >>>> in saying that this is a (std)library problem, it is not fully so. We >>>> would need a few primitives from the underlying PVM substrate. Possibly >>>> one reason for Guido's position is the lack of clarity as to what needs >>>> to be changed and why. IMHO, just saying take GIL off does not solve the >>>> problem either. >>>> >>>> >>> Before I can meaningfully comment I think I'd like to hear more about >>> what specifically you are thinking of. >>> >>> I don't mind the necessary changes to the PVM. I do like to see how >>> this affects existing C extensions though. >>> >>> >>> >> > > >
_______________________________________________ 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
