Re: [EVALUATION] - E01: The Java Failure - May Python Helps?
>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, no, NO! N'YH *insert ripping and splashing sounds* -- http://mail.python.org/mailman/listinfo/python-list
Re: Python versus Perl ?
> 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 person's code. Python and Perl accomplish similar things, but have strikingly different design philosophies. Perl's design philosophy is the kitchen sink: throw it all in. Python's is, "let's keep this simple." We add things carefully, and with great deliberation, or not at all. As a consequence, Python is far easier to learn than Perl. This has non-trivial consequences on your enterprise operations. For example, getting new engineers up to speed on the old code base is a great deal easier. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
>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 qualify. It's a question of /distribution/. If you copy parts of the work, and redestribute those copies, you are caught by the rule of law. After that the license is a matter of reduction to practice. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
>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 diatribe. But then I realized you are specifically speaking of the GPL's language. I once wrote RMS specifically on this subject. Back then, he agreed that it was ambiguous. The language of the GPL has changed over the years; and you are right: the court would have to rule about the terms, quite specifically because it would be reasonable to quibble over what rights have or have not been granted. My long diatribe was on copyright law itself. Not pertinent. Motion to strike and all that. :-) C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
>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, but TrollTech says the GPL doesn't allow a >proprietary program to make calls to the Qt library. That's their prerogative, although TrollTech's authority as an /interpretational/ entity over the GPL means precisely zero. I wouldn't push this, though, unless you've got a big litigation budget. >It's this double-standard that I find confusing, since both projects >are said to be based on the same license. Linus doesn't use "the" GPL, he uses "his" GPL, version-whatever. Anyway, your safe bet: Follow the copyright holder's wishes. That's fair. After all, it's free, so they're doing you a damn big favor. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
>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 that you *knew* what their interpretation ... But it doesn't. They'd really need to put it into their license expressly. Anyway, we digress, and are in agreement. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python as capable as Perl for sysadmin work?
>> 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 better than C++. I would /much/ rather manage a million lines of Python than a million lines of C++. *checks self to see if self is wearing rose colored glasses* *doesn't think so* C// -- http://mail.python.org/mailman/listinfo/python-list
Re: A 'Python like' language
>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 would go for it. C/// -- http://mail.python.org/mailman/listinfo/python-list
Re: Python v.s. c++
>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
Re: THREAD_STACK_SIZE and python performance?
>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 be; I'd think there'd not be one, with any reasonable amount of memory on your server. C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Kill GIL (was Re: multi threading in multi processor (computer))
>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, something to plan for the future canvas upon which our painting is painted... C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Kill GIL
>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 arbitrarily large numbers of threads at a problem, on a multi processor machine, on a problem that was intrinsically IO-bound. The ease with which one can get into problems with threads (and these days, also with network comms) leads to many problems if the engineers aren't acquainted sufficiently with the theory. Don't get me started on the big clusterfucks I've seen evolve from CORBA... C// -- http://mail.python.org/mailman/listinfo/python-list
Re: Kill GIL
>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 the right entity for dealing with asynchronicity, one might say. C// -- http://mail.python.org/mailman/listinfo/python-list
