"Jorgen Grahn" <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Apr 2007 08:05:01 +0200, Hendrik van Rooyen <[EMAIL PROTECTED]>
wrote:
> > "Jorgen Grahn" <[EMAIL PROTECTED]> wrote:
> ...
> >> I doubt it. (But I admit that I am a bit negative towards thread
> >> programming in general, and I have whined ab
Jorgen Grahn wrote:
> On Wed, 25 Apr 2007 08:05:01 +0200, Hendrik van Rooyen <[EMAIL PROTECTED]>
> wrote:
>
>>"Jorgen Grahn" <[EMAIL PROTECTED]> wrote:
> Eric Raymond's "The Art of Unix Programming" sums up the threading
> criticism, I think:
>
> http://catb.org/~esr/writings/taoup/html/multipr
On Tue, 24 Apr 2007 07:49:46 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Jorgen Grahn <[EMAIL PROTECTED]> wrote:
>...
>> > Perhaps the current wave of dual-core and quad-core CPUs in cheap
>> > consumer products would change people's perceptions -- I wonder...
>>
>> Maybe it would change
On Wed, 25 Apr 2007 08:05:01 +0200, Hendrik van Rooyen <[EMAIL PROTECTED]>
wrote:
> "Jorgen Grahn" <[EMAIL PROTECTED]> wrote:
...
>> I doubt it. (But I admit that I am a bit negative towards thread
>> programming in general, and I have whined about this before.)
>>
>
> I find this last statement
On 25 Apr., 16:09, Steve Holden <[EMAIL PROTECTED]> wrote:
> > Python as a language is in good shape. But the CPython
> > implementation is holding back progress. What we need are better
> > and faster implementations of the language we've got.
>
> Hear, hear!
>
> > PyPy, ShedSkin, and
John Nagle wrote:
> Alex Martelli wrote:
>> Jorgen Grahn <[EMAIL PROTECTED]> wrote:
>>...
>>
Perhaps the current wave of dual-core and quad-core CPUs in cheap
consumer products would change people's perceptions -- I wonder...
>
>> IronPython would appear to be coming along nicely and
"Jorgen Grahn" <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Apr 2007 20:39:57 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > Steve Holden <[EMAIL PROTECTED]> wrote:
> >
> >> A long time ago Greg Stein produced a patch that removed the need for
> >> the GIL, but nobody seemed to want to pay the pen
John Nagle <[EMAIL PROTECTED]> wrote:
...
> >>>Perhaps the current wave of dual-core and quad-core CPUs in cheap
> >>>consumer products would change people's perceptions -- I wonder...
>
> > IronPython would appear to be coming along nicely and getting acceptance
> > in the Windows community, a
Alex Martelli wrote:
> Jorgen Grahn <[EMAIL PROTECTED]> wrote:
>...
>
>>>Perhaps the current wave of dual-core and quad-core CPUs in cheap
>>>consumer products would change people's perceptions -- I wonder...
> IronPython would appear to be coming along nicely and getting acceptance
> in the
Jorgen Grahn <[EMAIL PROTECTED]> wrote:
...
> > Perhaps the current wave of dual-core and quad-core CPUs in cheap
> > consumer products would change people's perceptions -- I wonder...
>
> Maybe it would change /perceptions/, but would normal users suddenly
> start running things that are (a) p
Jorgen Grahn wrote:
> On Thu, 19 Apr 2007 20:39:57 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Steve Holden <[EMAIL PROTECTED]> wrote:
>>
>>> A long time ago Greg Stein produced a patch that removed the need for
>>> the GIL, but nobody seemed to want to pay the penalty it extracted in
>>> sp
On Thu, 19 Apr 2007 20:39:57 -0700, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Steve Holden <[EMAIL PROTECTED]> wrote:
>
>> A long time ago Greg Stein produced a patch that removed the need for
>> the GIL, but nobody seemed to want to pay the penalty it extracted in
>> speed reduction, so it langui
Steve Holden wrote:
> Marc 'BlackJack' Rintsch wrote:
>
>> In <[EMAIL PROTECTED]>, John Nagle wrote:
>>
>>> Many cases are easy. If a smart compiler sees
>>>
>>> for i in range(n) :
>>>... # something
>>>
>>> and there are no other assignments to "i", then it's clear that
>>> "i"
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, John Nagle wrote:
>
>> Many cases are easy. If a smart compiler sees
>>
>> for i in range(n) :
>> ... # something
>>
>> and there are no other assignments to "i", then it's clear that
>> "i" can be represented as an intege
In <[EMAIL PROTECTED]>, John Nagle wrote:
> Many cases are easy. If a smart compiler sees
>
> for i in range(n) :
> ... # something
>
> and there are no other assignments to "i", then it's clear that
> "i" can be represented as an integer, without "boxing" into a
> general ob
Alex Martelli wrote:
> Steve Holden <[EMAIL PROTECTED]> wrote:
>
>> A long time ago Greg Stein produced a patch that removed the need for
>> the GIL, but nobody seemed to want to pay the penalty it extracted in
>> speed reduction, so it languished unadopted.
>
> Perhaps the current wave of dual-c
Steve Holden <[EMAIL PROTECTED]> wrote:
> A long time ago Greg Stein produced a patch that removed the need for
> the GIL, but nobody seemed to want to pay the penalty it extracted in
> speed reduction, so it languished unadopted.
Perhaps the current wave of dual-core and quad-core CPUs in cheap
Michael Hoffman <[EMAIL PROTECTED]> wrote:
> S.Mohideen wrote:
>
> > I was thinking about the feasbility of adjusting Python as a
> > compiled language.
>
> In addition to the Python compilers listed by Steve, there is also
> Pyrex, which translates a Python-like language to C, and allo
Jorgen Grahn wrote:
> On Thu, 19 Apr 2007 10:56:25 -0600, S.Mohideen <[EMAIL PROTECTED]> wrote:
[...]
>
>> 4) Acheive true parallelism and performance by getting rid of the
>> middle-man Interpreter and GIL.
>
> Is the GIL really an artifact of the interpreter?
>
In so far as only the CPython
> Hi All,
> I was thinking about the feasbility of adjusting Python as a
> compiled language. Being said that I feel these are the following advantages
> of doing so --
> 1) Using the powerful easy-to -use feature of Python programming language
> constructs.
> 2) Making the program to ru
DillonCo wrote:
> On Thursday 19 April 2007, S.Mohideen wrote:
>
>> 2) Making the program to run at par with the compiled version of C/C++
>>program- this is the main benefit which can be derived out of this.
>
>
> Python is a rather slow language because of how it works. Even if you got
> rid
On Thursday 19 April 2007, S.Mohideen wrote:
> 2) Making the program to run at par with the compiled version of C/C++
> program- this is the main benefit which can be derived out of this.
Python is a rather slow language because of how it works. Even if you got rid
of the VM (as noted by others
On Thu, 19 Apr 2007 10:56:25 -0600, S.Mohideen <[EMAIL PROTECTED]> wrote:
> Hi All,
> I was thinking about the feasbility of adjusting Python as a
> compiled language. Being said that I feel these are the following advantages
> of doing so --
> 1) Using the powerful easy-to -use feature
S.Mohideen wrote:
> I was thinking about the feasbility of adjusting Python as a
> compiled language.
Python is a compiled language. It's compiled from source code to byte
code. That's what the .pyc files are.
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
S.Mohideen wrote:
> I was thinking about the feasbility of adjusting Python as a
> compiled language.
In addition to the Python compilers listed by Steve, there is also
Pyrex, which translates a Python-like language to C, and allows one to
interact with it from Python with very little
John Nagle wrote:
> S.Mohideen wrote:
>> Hi All,
>> I was thinking about the feasbility of adjusting Python as a
>> compiled language. Being said that I feel these are the following
>> advantages of doing so --
>> 1) Using the powerful easy-to -use feature of Python programming
>> langua
S.Mohideen wrote:
> Hi All,
> I was thinking about the feasbility of adjusting Python as a
> compiled language. Being said that I feel these are the following
> advantages of doing so --
> 1) Using the powerful easy-to -use feature of Python programming
> language constructs.
> 2) Making
Hi All,
I was thinking about the feasbility of adjusting Python as a
compiled language. Being said that I feel these are the following advantages
of doing so --
1) Using the powerful easy-to -use feature of Python programming language
constructs.
2) Making the program to run at par wi
28 matches
Mail list logo
