>Actually, this is one of the cases I was talking about. I find it
>saner to convert to non-blocking I/O and use select() for
>synchronization. That solves the problem, without introducing any of
>the headaches related to shared access and locking that come with
>threads.
Threads aren't always th
>Here here. I find that threading typically introduces worse problems
>than it purports to solve.
I recently worked on a software effort, arguably one of the most
important software efforts in existence, in which individuals
responsible for critical performance of the application threw
arbitraril
>Killing the GIL is proposing a silver bullet where there is no werewolf-ly,
About the only reason for killing the GIL is /us/. We, purists,
pythonistas, language nuts, or what not, who for some reason or
other simply hate the idea of the GIL. I'd view it as an artistic
desire, unurgent, somethin
>The FreeBSD patch, setting the value to 0x10
>seems to be enough for most of our zope servers,...
Is that value in /bytes/? In modern solaris implementations
of posix threads, the default stack size is 2 megabytes fo 64
bit machines.
I can't fathom what your performance consideration would
>Joking aside, you will love python and is well worth it since you can
>still use your c++ skills.
If a program is fine art, Python is my medium, upon which I paint my
imagination, without any thought of the canvas before me.
C//
--
http://mail.python.org/mailman/listinfo/python-list
>We really need in Python a clear separation of advanced features from
>the basic syntax. No more lambda calculus in the basic part. :>)
Well I considered writing a pep to move all that stuff to a module
called __icky__, you know:
from __icky__ import *
... but I didn't think the committee wou
>> Well, that's where Python helps you out compared to
>> Perl. Python can be a bit clumsier than Perl for dirt-simple tasks, but
>> you'll find that Python scales much better than Perl.
My opinion:
If "scales" refers to the /manageability/ of the code produced,
I'd say that Python scales bett
>It should also be pointed out that the FSF's interpretation of the GPL
>with respect to Qt means absolutely zero.
Indeed. It would be the court that would have to decide what the
language of the GPL means, given the substantial body of case
law as the court sees it.
>... but it establishes tha
>OK, so according to Linus, the GPL allows
No. Pay attention. Linus has his own revised version, to clarify
this point, and in fact /overruling/ the GPL if the point is
clarified differently by RMS or others.
That's the right of their community, it's /their/ code.
>make calls to the kernel
>Now, that's not to say that they are correct in their interpretation of
>the GPL's terms. In fact, if I had to bet on an outcome, I'd probably
>wager that the court would hold that only static linking would force the
>program as a whole to follow the GPL terms.
I just wrote and deleted a long
>If dynamic, then, it doesn't make sense that an EXE that builds on Qt
>should also be GPLed.
I'm hoping you're referring to the owners choice of license. For example,
if someone, owning rights to a thing that was a dynamic library, decided
to have a license akin to the GPL, it would easily quali
> If Python is better than Perl, I'm curious how really significant
>those advantages are ?
The main advantage is Python's cleanliness. In Perl, there are so
many different ways of writing a thing, that to be adept in perl,
you have to know them all, otherwise you won't be able to read another
p
>Well, we don't have to ban them because we have the PSU eliminate them
>alltogether. So much more efficient. Or do you think it's a coincidence
>we've never seen or heard Timothy "autocoding" Rue again?
Foolish, man! You said his name! It's almost like you said C'thul'hu, ...
you ... ah no
13 matches
Mail list logo
