Where is Guido ? would be great to hear his opinion on GIL/ GC issues in future versions of Python.
regards,
KM
On 7 Sep 2006 08:02:57 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
On 2006-09-06, [EMAIL PROTECTED] <
On 2006-09-06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Paul Rubin wrote:
>> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>> > (1) I think is here to stay, if you're going to tell programmers that
>> > their destructors can't make program-visible changes (e.g. closing the
>> > database con
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> If they don't get GC'd, then "when they are GC'd" is never. The point
> is that the standard library _does_ close files and take other
> program-visible actions in __del__ methods; I'm unclear on if you think
> that doing so is actually sloppy prac
Paul Rubin wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > > We had that debate already (PEP 343). Yes, there is some sloppy
> > > current practice by CPython users that relies on the GC to close the
> > > db conn.
> >
> > This point is unrelated to with or ref-counting. Even the sta
On 06 Sep 2006 13:29:33 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid>
wrote:
>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>> > We had that debate already (PEP 343). Yes, there is some sloppy
>> > current practice by CPython users that relies on the GC to close the
>> > db conn.
>>
>> Thi
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > We had that debate already (PEP 343). Yes, there is some sloppy
> > current practice by CPython users that relies on the GC to close the
> > db conn.
>
> This point is unrelated to with or ref-counting. Even the standard
> library will close fi
Here's a relevant post
http://mail.python.org/pipermail/python-3000/2006-April/001051.html
or
http://tinyurl.com/fod9u
[EMAIL PROTECTED] wrote:
> Andre> This seems to be an important issue and fit for discussion in the
> Andre> context of Py3k. What is Guido's opinion?
>
> Dunno. I've nev
I wrote:
> Ah, O.K. Like Paul, I was unaware how Unix file worked with
> mmap.
Insert "locking" after "file".
--
--Bryan
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > (1) I think is here to stay, if you're going to tell programmers that
> > their destructors can't make program-visible changes (e.g. closing the
> > database connection when a dbconn is destroyed), that's a _huge_ change
> > fr
[EMAIL PROTECTED] wrote:
> Bryan Olson wrote:
>> I think it's even worse. The standard Python library offers
>> shared memory, but not cross-process locks.
>
> File locks are supported by the standard library (at least on Unix,
> I've not tried on Windows). They work cross-process and are a norma
You can use multiple processes to simulate threads via an IPC
mechanism. I use D-Bus to achieve this.
http://www.freedesktop.org/wiki/Software/dbus
km wrote:
> Hi all,
> Are there any alternate ways of attaining true threading in python ?
> if GIL doesnt go then does it mean that python is usele
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Throwing them out without careful consideration is a bad
>idea--ref-counting is _not_ simply one GC implementation among many, it
>actually offers useful semantics and the cost of giving up those
>semantics should be considered before throwing out
Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Paul Rubin wrote:
> >
> >>Jean-Paul Calderone <[EMAIL PROTECTED]> writes:
> >>
> which more explicitly shows the semantics actually desired. Not that
> "huge" a benefit as far as I can tell. Lisp programmers have gotten
> along fine w
[EMAIL PROTECTED] wrote:
> Paul Rubin wrote:
>
>>Jean-Paul Calderone <[EMAIL PROTECTED]> writes:
>>
which more explicitly shows the semantics actually desired. Not that
"huge" a benefit as far as I can tell. Lisp programmers have gotten
along fine without it for 40+ years...
>>>
>>>U
[EMAIL PROTECTED] wrote:
> Paul Rubin wrote:
>
>>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>>
>>>Having memory protection is superior to not having it--OS designers
>>>spent years implementing it, why would you toss out a fair chunk of it?
>>> Being explicit about what you're sharing is gene
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> You can, absolutely. If you're sharing memory through mmap it's
> usually the preferred solution; fcntl locks ranges of an open file, so
> you lock exactly the portions of the mmap that you're using at a given
> time.
How can it do that without ha
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > Part of the win of programming in Python instead of C is having the
> > language do memory management for you--no more null pointers
> > dereferences or malloc/free errors. Using shared memory puts all that
> > squarely back in your lap.
>
> Huh
Paul Rubin wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > > I think it's even worse. The standard Python library offers
> > > shared memory, but not cross-process locks.
> >
> > File locks are supported by the standard library (at least on Unix,
> > I've not tried on Windows). They w
Paul Rubin wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > Having memory protection is superior to not having it--OS designers
> > spent years implementing it, why would you toss out a fair chunk of it?
> > Being explicit about what you're sharing is generally better than not.
>
> Par
Paul Rubin wrote:
> Jean-Paul Calderone <[EMAIL PROTECTED]> writes:
> > >which more explicitly shows the semantics actually desired. Not that
> > >"huge" a benefit as far as I can tell. Lisp programmers have gotten
> > >along fine without it for 40+ years...
> >
> > Uh yea. No lisp programmer ha
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > I think it's even worse. The standard Python library offers
> > shared memory, but not cross-process locks.
>
> File locks are supported by the standard library (at least on Unix,
> I've not tried on Windows). They work cross-process and are a n
Jean-Paul Calderone <[EMAIL PROTECTED]> writes:
> >which more explicitly shows the semantics actually desired. Not that
> >"huge" a benefit as far as I can tell. Lisp programmers have gotten
> >along fine without it for 40+ years...
>
> Uh yea. No lisp programmer has ever written a with-* funct
On 05 Sep 2006 17:31:11 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid>
wrote:
>
> def func(filename):
> with open(filename) as f:
>do_something_with(f)
> # f definitely gets closed when the "with" block exits
>
>which more explicitly shows the semantics actually desired. Not
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Having memory protection is superior to not having it--OS designers
> spent years implementing it, why would you toss out a fair chunk of it?
> Being explicit about what you're sharing is generally better than not.
Part of the win of programming i
On 05 Sep 2006 13:19:03 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid>
wrote:
>[EMAIL PROTECTED] writes:
>> It was removed at one point in the dim, dark past (circa Python 1.4) on an
>> experimental basis. Aside from the huge amount of work, it resulted in
>> significantly lower performance f
[EMAIL PROTECTED] writes:
> It was removed at one point in the dim, dark past (circa Python 1.4) on an
> experimental basis. Aside from the huge amount of work, it resulted in
> significantly lower performance for single-threaded apps (that is, the
> common case).
That's probably because they had
[EMAIL PROTECTED] wrote:
> You can do the same on Windows if you use CreateProcessEx to create the
> new processes and pass a NULL SectionHandle. I don't think this helps
> in your case, but I was correcting your impression that "you'd have to
> physically double the computer's memory for a dual c
Andre> This seems to be an important issue and fit for discussion in the
Andre> context of Py3k. What is Guido's opinion?
Dunno. I've never tried channeling Guido before. You'd have to ask him.
Well, maybe Tim Peters will know. He channels Guido on a fairly regular
basis.
Skip
--
htt
Lawrence Oluyede <[EMAIL PROTECTED]> wrote:
> Take a look here:
> http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/00
> 2049.html
> and this thread:
> http://www.mail-archive.com/users@lists.ironpython.com/msg01826.html
Also this: http://www.codeproject.com/useritems/ipaspnet
Sandra-24 <[EMAIL PROTECTED]> wrote:
> Oh I'm aware of that, but it's not what I'm looking for. Mod_mono just
> lets you run ASP.NET on Apache. I'd much rather use Python :) Now if
> there was a way to run IronPython on Apache I'd be interested.
Take a look here:
http://lists.ironpython.com/piper
This seems to be an important issue and fit for discussion in the context of Py3k. What is Guido's opinion?As a developer of a multi-threaded system I would like to know more about these issues, so it's no time wasted for me... ;-)
regardsAndreOn 9/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Bryan Olson wrote:
> I think it's even worse. The standard Python library offers
> shared memory, but not cross-process locks.
File locks are supported by the standard library (at least on Unix,
I've not tried on Windows). They work cross-process and are a normal
method of interprocess locking ev
Richard> It would probably be easier to find smarter friends than to
Richard> remove the GIL from Python.
And if the friends you find are smart enough, they can remove the GIL for
you!
Skip
--
http://mail.python.org/mailman/listinfo/python-list
Steve> Given the effort that GIL-removal would take, I'm beginning to
Steve> wonder if PyPy doesn't offer a better way forward than CPython,
Steve> in terms of execution speed improvements returned per
Steve> developer-hour.
How about execution speed improvements per hour of discu
[EMAIL PROTECTED] wrote:
> Sandra> However, I don't expect that the GIL can be safely removed from
> Sandra> CPython.
>
> It was removed at one point in the dim, dark past (circa Python 1.4) on an
> experimental basis. Aside from the huge amount of work, it resulted in
> significantly low
"km" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> True, since smartness is a comparison, my friends who have chosen java
> over python for considerations of a true threading support in a
> language are smarter, which makes me a dumbo ! :-)
No, but I think you making unwise assu
True, since smartness is a comparison, my friends who have chosen java
over python for considerations of a true threading support in a
language are smarter, which makes me a dumbo ! :-)
KM
On 9/5/06, Richard Brodie <[EMAIL PROTECTED]> wrote:
>
> "km" <[EMAIL PROTECTED]> wrote in message
> news:[
"km" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I know many of my friends who did not choose python for obvious reasons
> of the nature of thread execution in the presence of GIL which means
> that one is wasting sophisticated hardware resources.
It would probably be easier
Paul Rubin wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>> If it's read/write data or you're not on a Unix platform, you can use
>> shared memory to shared it between many processes.
>>
>> Threads are way overused in modern multiexecution programming. The
>> decision on whether to use
Sandra-24 wrote:
> > You seem to be confused about the nature of multiple-process
> > programming.
> >
> > If you're on a modern Unix/Linux platform and you have static read-only
> > data, you can just read it in before forking and it'll be shared
> > between the processes..
>
> Not familiar with *
Hi all,
> And yet, Java programmers manage to write threaded applications all
> day long without getting bitten (once they're used to the issues),
> despite usually being less skilled than Python programmers ;-).
> These days, even semi-entry-level consumer laptop computers have dual
> core CPU's,
Felipe Almeida Lessa wrote:
> 4 Sep 2006 19:19:24 -0700, Sandra-24 <[EMAIL PROTECTED]>:
> > If there was a mod_dotnet I wouldn't be using
> > CPython anymore.
>
> I guess you won't be using then: http://www.mono-project.com/Mod_mono
>
Oh I'm aware of that, but it's not what I'm looking for. Mod_mon
Sandra> However, I don't expect that the GIL can be safely removed from
Sandra> CPython.
It was removed at one point in the dim, dark past (circa Python 1.4) on an
experimental basis. Aside from the huge amount of work, it resulted in
significantly lower performance for single-threaded a
bayerj wrote:
> Then you can use POSH [1] to share data and objects.
Do you use POSH? How well does it work with current Python?
Any major gotchas?
I think POSH looks like a great thing to have, but the latest
version is an alpha from over three years ago. Also, it only
runs on *nix systems.
-
Steve Holden wrote:
> Quite right too. You haven't even sacrificed a chicken yet ...
Hopefully we don't get to that point.
> You write as though the GIL was invented to get in the programmer's way,
> which is quite wrong. It's there to avoid deep problems with thread
> interaction. Languages tha
4 Sep 2006 19:19:24 -0700, Sandra-24 <[EMAIL PROTECTED]>:
> If there was a mod_dotnet I wouldn't be using
> CPython anymore.
I guess you won't be using then: http://www.mono-project.com/Mod_mono
--
Felipe.
--
http://mail.python.org/mailman/listinfo/python-list
Steve Holden <[EMAIL PROTECTED]> writes:
> You write as though the GIL was invented to get in the programmer's
> way, which is quite wrong. It's there to avoid deep problems with
> thread interaction. Languages that haven't bitten that bullet can bite
> you in quite nasty ways when you write thread
Sandra-24 wrote:
[Sandra understands shared memory]
>
> I would find an easier time, I think, porting mod_python to .net and
> leaving that GIL behind forever. Thankfully, I'm not considering such
> drastic measures - yet.
>
Quite right too. You haven't even sacrificed a chicken yet ...
> Why on
> You seem to be confused about the nature of multiple-process
> programming.
>
> If you're on a modern Unix/Linux platform and you have static read-only
> data, you can just read it in before forking and it'll be shared
> between the processes..
Not familiar with *nix programming, but I'll take y
Rob Williscroft wrote:
> Daniel Dittmar wrote in news:[EMAIL PROTECTED] in
> comp.lang.python:
>
>
>>- removing reference counting and relying on garbage collection alone
>>will break many Python applications (because they rely on files being
>>closed at end of scope etc.)
>>
>
>
> They are
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> If it's read/write data or you're not on a Unix platform, you can use
> shared memory to shared it between many processes.
>
> Threads are way overused in modern multiexecution programming. The
> decision on whether to use processes or threads sho
Sandra-24 wrote:
> The trouble is there are some environments where you are forced to use
> threads. Apache and mod_python are an example. You can't make use of
> mutliple CPUs unless you're on *nux and run with multiple processes AND
> you're application doesn't store large amounts of data in memo
Daniel Dittmar wrote in news:[EMAIL PROTECTED] in
comp.lang.python:
> - removing reference counting and relying on garbage collection alone
> will break many Python applications (because they rely on files being
> closed at end of scope etc.)
>
They are already broken on at least 2 python imp
km wrote:
> Is there any PEP to introduce true threading features into python's
> next version as in java? i mean without having GIL.
> when compared to other languages, python is fun to code but i feel its
> is lacking behind in threading
Some of the technical problems:
- probably breaks compati
The trouble is there are some environments where you are forced to use
threads. Apache and mod_python are an example. You can't make use of
mutliple CPUs unless you're on *nux and run with multiple processes AND
you're application doesn't store large amounts of data in memory (which
mine does) so y
Sybren Stuvel wrote:
> km enlightened us with:
>> Is there any PEP to introduce true threading features into python's
>> next version as in java? i mean without having GIL.
>
> What is GIL? Except for the Dutch word for SCREAM that is...
the global interpreter lock, that prevents python from con
On Mon, 4 Sep 2006 17:48:14 +0200, Sybren Stuvel <[EMAIL PROTECTED]> wrote:
>km enlightened us with:
>> Is there any PEP to introduce true threading features into python's
>> next version as in java? i mean without having GIL.
>
>What is GIL? Except for the Dutch word for SCREAM that is...
>
>> whe
km enlightened us with:
> Is there any PEP to introduce true threading features into python's
> next version as in java? i mean without having GIL.
What is GIL? Except for the Dutch word for SCREAM that is...
> when compared to other languages, python is fun to code but i feel
> its is lacking be
"km" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> if GIL doesnt go then does it mean that python is useless for
> computation intensive scientific applications which are in need of
> parallelization in threading context ?
No.
--
http://mail.python.org/mailman/listinfo/pyth
Hi,
You might want to split your calculation onto different
worker-processes.
Then you can use POSH [1] to share data and objects.
You might even want to go a step further and share the data via
Sockets/XML-RPC or something like that. That makes it easy to throw
aditional boxes at a specific calc
Hi all,
Are there any alternate ways of attaining true threading in python ?
if GIL doesnt go then does it mean that python is useless for
computation intensive scientific applications which are in need of
parallelization in threading context ?
regards,
KM
Hi,
GIL won't go. You might want to read
http://blog.ianbicking.org/gil-of-doom.html .
Regards,
-Justin
--
http://mail.python.org/mailman/listinfo/python-list
Hi all,
Is there any PEP to introduce true threading features into python's
next version as in java? i mean without having GIL.
when compared to other languages, python is fun to code but i feel its
is lacking behind in threading
regards,
KM
--
http://mail.python.org/mailman/listinfo/python-list
63 matches
Mail list logo
