>From over yonder, on python-dev...
> -- Forwarded message --
> From: Steve Dower
> Subject: Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
>
> "Go ahead, make my pep."
>
> We should make a python-dev t-shirt with this o
On Sat, Jun 26, 2010 at 7:11 AM, Nobody wrote:
> On Fri, 25 Jun 2010 20:08:27 -0400, geremy condra wrote:
>
>> I have written Haskell that runs faster than C, and Forth that runs
>> faster than C,
>
> Faster than *what* C, though?
Well, than the C it was replacing, which is admittedly not much
of
On Fri, 25 Jun 2010 20:08:27 -0400, geremy condra wrote:
> I have written Haskell that runs faster than C, and Forth that runs
> faster than C,
Faster than *what* C, though?
With Haskell, there's seldom a significant performance hit for using
-fvia-C, so you would probably have been able to get
On Fri, Jun 25, 2010 at 6:18 PM, Mark Lawrence wrote:
> On 25/06/2010 22:25, Stephen Hansen wrote:
>>
>> On Fri, Jun 25, 2010 at 1:51 PM, Mark
>> Lawrencewrote:
>>
>>> On 25/06/2010 16:34, Stephen Hansen wrote:
>>>
>>> Python's slow, sure. But its in practice fast enough for an extremely
>>>
On Fri, Jun 25, 2010 at 3:18 PM, Mark Lawrence wrote:
> On 25/06/2010 22:25, Stephen Hansen wrote:
>
>> On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrence> >wrote:
>>
>> On 25/06/2010 16:34, Stephen Hansen wrote:
>>>
>>> Python's slow, sure. But its in practice fast enough for an extremely
>>>
On 25/06/2010 22:25, Stephen Hansen wrote:
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrencewrote:
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely
broad
range of activities.
What?
What, what?
--S
Python is *NOT* slow,
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrence wrote:
> On 25/06/2010 16:34, Stephen Hansen wrote:
>
> Python's slow, sure. But its in practice fast enough for an extremely
>> broad
>> range of activities.
>>
>>
> What?
>
What, what?
--S
--
http://mail.python.org/mailman/listinfo/python-list
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely broad
range of activities.
What?
Kindest regards.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Jun 24, 2010 at 7:52 PM, Peng Yu wrote:
> http://psyco.sourceforge.net/
>
> The above package can improve python program on 32 bit library. But I
> need to run on 64 bit library. Is there any other module that can help
> improving the performance of python on 64 bit?
>
This is a total as
On Fri, Jun 25, 2010 at 7:01 AM, Tim Wintle wrote:
> On Thu, 2010-06-24 at 21:52 -0500, Peng Yu wrote:
>> http://psyco.sourceforge.net/
>>
>> The above package can improve python program on 32 bit library. But I
>> need to run on 64 bit library. Is there any other module that can help
>> improving
On Thu, 2010-06-24 at 21:52 -0500, Peng Yu wrote:
> http://psyco.sourceforge.net/
>
> The above package can improve python program on 32 bit library. But I
> need to run on 64 bit library. Is there any other module that can help
> improving the performance of python on 64 bit?
As I understand it
http://psyco.sourceforge.net/
The above package can improve python program on 32 bit library. But I
need to run on 64 bit library. Is there any other module that can help
improving the performance of python on 64 bit?
--
Regards,
Peng
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> wrote:
>Aahz wrote:
>> In article <[EMAIL PROTECTED]>,
>> Steve Holden <[EMAIL PROTECTED]> wrote:
>.>
>>>Bear in mind that the PSF made its very first grants last year. The
>>>reason none of those grants was awarded to a documenta
Aahz wrote:
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
func(*arg) instead of apply() is a step back -- it hides the fact
that functions are objects, and it confuses the heck out of both
C/C++ programmers and Python programmers that understand the "def
func(*arg)" form,
Dima Dorfman wrote:
> I happen to not mind the ''.join syntax, but if I did, I would use
>
> str.join('', seq)
>
> which is just like a join builtin except that it's not as easy to make
> it work on pre-string-method Pythons.
just like join, except that it isn't:
>>> string.join(seq, sep)
u'axb
[EMAIL PROTECTED] (Aahz) writes:
> While I'm in complete agreement about the "".join() construct on the
> basis of looks, I have come to appreciate the fact that I *never* mess up
> the order of arguments any more.
Yeah. When I needed joinable arrays of strings in Eiffel, I added them
to the ARRA
On 2004-12-26, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> string methods are nice, but nothing groundbreaking, and their niceness is
> almost entirely offset by the horrid "".join(seq) construct that keeps popping
> up when people take the "the string module is deprecated" yada yada too
> seriously
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>func(*arg) instead of apply() is a step back -- it hides the fact
>that functions are objects, and it confuses the heck out of both
>C/C++ programmers and Python programmers that understand the "def
>func(*arg)" form, becau
In article <[EMAIL PROTECTED]>,
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> func(*arg) instead of apply() is a step back
Strongly disagree. I find func(*args) much more readable than
apply(func, args).
> -- it hides the fact that functions are objects,
What does this have to do with anything
Aahz wrote:
>>(I've said it before, and I'll say it again: native unicode and
>>generators are the only essential additions I've seen since 1.5.2, with
>>properties and sub-classable C types sharing a distant third place.
>>the rest of the stuff has had zero impact on my ability to write solid
>>c
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>(I've said it before, and I'll say it again: native unicode and
>generators are the only essential additions I've seen since 1.5.2, with
>properties and sub-classable C types sharing a distant third place.
>the rest of the
Skip Montanaro wrote:
>
>Keith> My personal gripe is this. I think the core language, as of 2.3
>Keith> or 2.4 is very good, has more features than most people will ever
>Keith> use, and they (Guido, et al.) can stop tinkering with it now and
>Keith> concentrate more on the standard
Keith> My personal gripe is this. I think the core language, as of 2.3
Keith> or 2.4 is very good, has more features than most people will ever
Keith> use, and they (Guido, et al.) can stop tinkering with it now and
Keith> concentrate more on the standard libraries.
What keeps you
23 matches
Mail list logo
