Re: The Industry choice
On Fri, 07 Jan 2005 12:06:42 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote: >Bulba! wrote: > >> On 6 Jan 2005 19:01:46 -0500, [EMAIL PROTECTED] (Aahz) wrote: >> >> >>>>Note that the so-called 'viral' nature of GPL code only applies to >>>>*modifications you make* to the GPL software. The *only* way in which >>>>your code can be 'infected' by the GPL is if you copy GPL source. >> >> >>>That's not true -- consider linking to a GPL library. >> >> >> Will someone please explain to me in simple terms what's >> the difference between linking to LGPLed library and linking >> to GPLed library - obviously in terms of consequences of >> what happens to _your_ source code? >> >> Because if there isn't any, why bother with distinguishing >> between the two? > >Releasing a product in which your code is linked together with GPL'ed >code requires that your code also be GPL'ed. The GPL goes to some >lengths to define what exactly "linked together" means. That looks like a typo. The LGPL goes to great length to how you can link to LGPL software without using either the LGPL or GPL. The GPL (linked to by fsf.org) merely states: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: Note that the conditions are all those of any program released under the GPL. Whatever "forming a work based on the Program" means is whatever you and the copyright owner agree to, or whatever copyright law considers a derived work in areas you wish to release your code into. I would suggest consulting a lawyer before getting close to the line, but you can expect that any legally enforceable restrictions claimed by FSF and/or RMS to be legally binding on all software released under the (L)GPL that the FSF owns the copyright of (they encourage programmers to sign over copyright to the FSF itself). > >Releasing a product in which your code is linked together with LGPL'ed >code does *not* require that your code also be (L)GPL'ed. Changes to >the core library must still be released under (L)GPL, but application >code which merely *uses* the library does not. (I've forgotten, now, >exactly how LGPL defines this distinction...) > >Jeff Shannon >Technician/Programmer >Credit International Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: python and gpl
On 30 Jan 2005 21:59:25 -0800, Paul Rubin
<http://[EMAIL PROTECTED]> wrote:
>John Hunter <[EMAIL PROTECTED]> writes:
>> The question is: does shipping a backend which imports a module that
>> links with GPL code make some or all of the library GPL.
>
>Literally speaking, no, not automatically, any more than driving a car
>makes you into a licensed driver if you weren't one already. But if
>you weren't licensed, then you've broken the law by driving the car.
>So your question should be: 1) is shipping that backend one of the
>things you need the GPL to license you to legally do, and 2) if so,
>does the GPL in fact give you that license?
>
>If you're asking in terms of legal enforcement, the answer is 1) maybe
>and 2) almost certainly not. I think it's better to ask in terms of
>the GPL's spirit. I would say that it's not in the GPL's spirit and
>that GPL die-hards would consider that use objectionable, though they
>might make exceptions for specific cases (so it doesn't hurt to ask).
>Some authors who use the GPL are less strict about how they interpret
>it, so again, the friendly thing to do is ask the author.
>
> * If a backend module somebackend does
>
> import somelib
>
>where somelib is a python wrapper of GPL code, is somebackend GPLd?
>
>It's GPL'd if you GPL it. If you don't GPL it, then distributing it
>it may be a GPL violation that could get you taken to court. I
>believe the FSF's view is that it is fact a violation; however, the
>courts have not yet established this. The law doesn't have a
>black-and-white boundary. It's more like a fractal. The only way to
>find out what a court will decide is to actually try a case there.
>
>Rather than try to probe how closely you can dance around the
>boundaries of the GPL, you might just ask the author of the GPL'd
>library whether what you want to do is ok with him or her. If s/he
>says no and you do it anyway, you're both inviting trouble over the
>possible infringement, and also inviting people to try to use your
>code in ways you don't like. Since the free software movement depends
>on a spirit of cooperation, I think it's best to avoid trying to press
>too hard against the boundaries of anyone's licenses.
>
>http://www.gnu.org/licenses/gpl-faq.html
If you read the GPL, it claims everything it can (any "work" created
using GPLed "work"). My guess is that anything that calls the code in
a way not specifically allowed by the author is going to get you into
trouble. IANAL, but from what I can remember about earlier licensing
issues, any code specific for a GPLed library (especially "import")
will get you into to trouble. Having a non-free library with an
identical API and issuing
exec("import "+sys.argv[1])
where the user can supply sys.argv as the name of the gpl'ed library
will work (I think there is a free/non-free library out there that is
never run, but exists for exactly this condition).
Scott Robinson
--
http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Mon, 07 Feb 2005 20:56:44 -0800, Courageous <[EMAIL PROTECTED]> wrote: > >>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 should also be pointed out that the FSF's interpretation of the GPL with respect to Qt means absolutely zero. If TrollTech publishes an interpretation of the GPL and announces it to any interested in licensing their software, I suspect that the courts will take that into consideration. This won't help that at all if it isn't a legally valid interpretation, but it establishes that you *knew* what their interpretation was when you agreed to the terms to distribute their copyrighted software. > >>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// Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: Tuple index
On 21 Feb 2005 15:01:05 -0800, "John Machin" <[EMAIL PROTECTED]> wrote: > >Steve M wrote: >> John Machin wrote: >> >> > >> > Steve M wrote: >> >> I'm actually doing this as part of an exercise from a book. What >the >> > program >> >> is supposed to do is be a word guessing game. The program >automaticly >> >> randomly selects a word from a tuple. >> > >> > Care to tell us which book is using a tuple for this, but hasn't >got to >> > lists yet? >> > >> > Cheers, >> > John >> >> Python Programming for the absoulte beginner by Michael Dawson > >In a review I found on the web: >http://www.skattabrain.com/css-books-plain/1592000738.html >"Dawson will take you by the hand and lead you down the garden path." > >Malapropism? Intentional humour? The book teaches you enough about programming and python to get you programming. It was the only python book in my local library so I read it while trying to learn the basics of python. It got me to the point where I could comfortably write Fortran-style python (I am not claiming that anyone else will leave the book that way, only that was as far as I had progressed in understanding python). I think that this book suggests using pickle/unpickle to send data over the internet. This is an amazingly bad idea, which is obvious once you understand how overloading works (I'm pretty sure overloading isn't covered in that book). In short, I think that this book is a good introduction to programming, and it will explain the basics of python, but it doesn't really begin to explain how to program in python. Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: GPL and Python modules.
On Mon, 25 Oct 2004 20:13:46 -0700, Robert Kern <[EMAIL PROTECTED]> wrote: >Tim Churches wrote: >> From: [EMAIL PROTECTED] >> >>>[mailto:[EMAIL PROTECTED] >>> On Behalf Of Robert Kern >>>Sent: Tuesday, 26 October 2004 11:34 AM >>>To: [EMAIL PROTECTED] >>>Subject: Re: GPL and Python modules. >>> >>> >>>Tim Churches wrote: >>> >>>>On Tue, 2004-10-26 at 11:12, Robert Kern wrote: >>> >>>>>Whether just using system calls is simply "normal use" for a GPLd OS >>>>>kernel or this is simply a special exception to the GPL for >>> >>>Linux only >>> >>>>>is something that a court will have to decide. But such a >>> >>>suit would >>> >>>>>have to be about some other GPL kernel, not Linux. >>>> >>>> >>>>Looks like it is a special exception for the Linux kernel >>> >>>(or whatever >>> >>>>other Linux code is distributed with this COPYING file. >>> >>>Doesn't apply >>> >>>>to other GPLed code. >>> >>>Well, not necessarily. It certainly isn't phrased as one. It >>>is at least >>>a statement of someone's (Linus's?) belief that standard applications >>>that only use system calls and running on Linux are not >>>derivative works >>>with respect to Linux. >> >> >> Yes, so it is a specific exemption to the GPL granted by the copyright >> holder(s) of the Linux kernel code. The GPL allows the copyright holder to >> grant exemptions to the GPL privisions as they see fit - but no-one else. > >It's still phrased as Linus's interpretation of what constitutes a >derivative work and what constitutes normal use of the GPLed kernel. >He's specifically saying that userland applications are not derivative >works not "even though they are derivative works, they are excepted from >the requirements of this license." > >>>Are Windows programs actual derivative >>>works of >>>the Windows kernel? Does the Windows EULA make a statement about the >>>derivative status of applications? >> >> >> No, and no. An important point of difference between the world views held >> by, say, Steve Ballmer and, say, Richard Stallman. > >The world views of Ballmer and Stallman are irrelevant to whether >something is a derivative or not. They may be relevant to whether one >may get sued or not, but that's a different issue. > >In any case, Stallman does not appear to believe that userland >applications are automatically derivative works of the kernel: > >http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem > >"""If the two programs remain well separated, like the compiler and the >kernel, or like an editor and a shell, then you can treat them as two >separate programs--but you have to do it properly.""" I would be careful in taking legal advise from Richard Stallman. The GPL merely states that*: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: After that, all notion of "derived work" falls on the appropriate copyright law of the country in question. I suspect that following Stallman's verdicts won't cause you to violate the GPL, but I would hardly be willing to be certain about going to court over a GPLed module imported into an unfree python program. Scott Robinson * note that I believe that this is fair use. According to the GPL, you can only distribute it unmodified. -- http://mail.python.org/mailman/listinfo/python-list
Re: Socket being garbage collected too early
On 16 Dec 2004 20:38:29 -0500, David Bolen <[EMAIL PROTECTED]> wrote:
>Scott Robinson <[EMAIL PROTECTED]> writes:
>
>> I have been having trouble with the garbage collector and sockets.
>
>Are you actually getting errors or is this just theoretical?
>
>> Unfortunately, google keeps telling me that the problem is the garbage
>> collector ignoring dead (closed?) sockets instead of removing live
>> ones. My problem is
>>
>>
>> x.sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
>> do_stuff(x.sock)
>>
>>
>> def do_stuff(sock):
>> sock_list.append(sock)
>>
>> once do_stuff finishes, x.sock disappears, and I can only believe it
>> is being garbage collected.
>
>Can you clarify this? What do you mean by "x.sock" disappears? Are
>you getting a NameError later when trying to use "x.sock"?
>
>x.sock is just a name binding, so it is not really involved in garbage
>collection (GC applies to the objects to which names are bound).
>
>In this case, you need to include much more in the way of code (a
>fully running, but smallest possible, snippet of code would be best),
>since the above can be interpreted many ways. At the least, it's very
>important to include information about the namespace within which
>those two code snippets run if anyone is likely to be able to give you
>a good answer. Also, being very precise about the error condition you
>are experiencing (including actual error messages, tracebacks, etc...)
>is crucial.
>
>Is 'x' referencing a local or global object, and does that socket code
>occur within a method, a function, or what? Also, in do_stuff, where
>is sock_list defined? Is it local, global?
>
>If, as written, sock_list is a local name to do_stuff, then that
>binding is going to disappear when do_stuff completes, thus, the list
>to which it is bound will be destroyed, including all references to
>objects that the list may contain. So at that point, when you return
>from do_stuff, the only reference to the socket object will be in
>x.sock. But if 'x' is also local to the function/method where the
>call to do_stuff is, the name binding will be removed when the
>function/method returns, at which point there will be no references to
>the socket object, and yes, it will be destroyed.
>
>But if sock_list is global, and continues to exist when do_stuff
>completes, then the reference it contains to the socket will keep the
>socket object alive even if you remove the x.sock binding.
>
>-- David
(so much for Python being executable psuedocode).
It looks like I was completely wrong. The problem I ran into was not
checking into baseHTTPserver and looking for self.close_connection=1.
I am pretty sure this happened to me before, and I rewrote the code to
avoid sockets being closed after being referenced to a live object,
but I can't reproduce it.
Anyway, here is my debugged test rig. It works. Ignore it.
Scott
[test program follows]
import socket, thread, time
class sock_holder:
pass
HOST = '127.0.0.1'
PORT = 2004
def echo_server(port):
print "started at",port
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((HOST, port))
s.listen(1)
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
if not data: break
conn.send(data)
conn.close()
def wait_and_speak(a):
time.sleep(5)
try:
a.sock.send("this is message 2")
except:
print "error on message 2"
try:
data = a.sock.recv(1024)
print data
except:
print "error recieving message 2"
a.sock.close()
def other_thread(a):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
thread.start_new(echo_server,(PORT,))
time.sleep(1)
s.connect((HOST,PORT ))
s.send('Hello, port 1')
data = s.recv(1024)
print data
a.sock=s
thread.start_new(wait_and_speak,(a,))
a=sock_holder()
thread.start_new(other_thread,(a,))
time.sleep(10)
--
http://mail.python.org/mailman/listinfo/python-list
Re: BASIC vs Python
On Fri, 17 Dec 2004 15:00:54 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote: >"not [quite] more i squared" <[EMAIL PROTECTED]> writes: > >> Adam DePrince wrote: >> Given the hardware constraints of the early 1980s, which language do you think should have been used instead of BASIC? >>> Lisp >>> Forth >> Exactly my pick > >Logo (my pick) has been called "Lisp without the parenthesis". It has >the advantage of using standard algebraic notation for formulas, >instead of operator post or pre. > >http://mail.python.org/mailman/listinfo/python-list
Socket being garbage collected too early
I have been having trouble with the garbage collector and sockets. Unfortunately, google keeps telling me that the problem is the garbage collector ignoring dead (closed?) sockets instead of removing live ones. My problem is x.sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM) do_stuff(x.sock) def do_stuff(sock): sock_list.append(sock) once do_stuff finishes, x.sock disappears, and I can only believe it is being garbage collected. I'd like to hear the standard means for avoiding this issue (gc appears to have only the interface to declare something garbage, not to declare something not garbage). Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: BASIC vs Python
On Fri, 17 Dec 2004 20:41:11 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote: >Scott Robinson <[EMAIL PROTECTED]> writes: > >> Forth seems better than basic, but is *weird* (I tried it for a >> while). I'm not sure going from Forth to C (or Python) would be much >> easier than Basic to C or Python. The biggest disappointment for >> Forth was that no significant Forth chips were made (and none until it >> was too late). A machine designed to be run on Forth would have been >> unbelievably powerful from the late 70s to the mid 90s (it would be >> more painful now than the x86 legacy, but still). > >I think you overestimate how long the Forth chip would have been a >serious competitor to x`the x86 line. LISP chips - which should have >all the same advantages - didn't last that long. > >http://mail.python.org/mailman/listinfo/python-list
Re: BASIC vs Python
On Fri, 17 Dec 2004 20:41:11 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote: >Scott Robinson <[EMAIL PROTECTED]> writes: > >> Forth seems better than basic, but is *weird* (I tried it for a >> while). I'm not sure going from Forth to C (or Python) would be much >> easier than Basic to C or Python. The biggest disappointment for >> Forth was that no significant Forth chips were made (and none until it >> was too late). A machine designed to be run on Forth would have been >> unbelievably powerful from the late 70s to the mid 90s (it would be >> more painful now than the x86 legacy, but still). > >I think you overestimate how long the Forth chip would have been a >serious competitor to x`the x86 line. LISP chips - which should have >all the same advantages - didn't last that long. > >http://mail.python.org/mailman/listinfo/python-list
Re: BASIC vs Python
On Mon, 20 Dec 2004 08:46:14 + (UTC), Alan Gauld <[EMAIL PROTECTED]> wrote: >> >>> was too late). A machine designed to be run on Forth would have been >> >>> unbelievably powerful from the late 70s to the mid 90s (it would be >> >>> more painful now than the x86 legacy, but still). > >A small data point here is that Sun still use Forth in their >Sparc workstations. Their system prompt is really a Forth >interpreter... I don;t know where the interpreter resides, >presumably not in Sparc since its a RISC but interesting that >they still use it. (Or they did last time I used a >Sparc - 4 years ago?) > >Alan G. >Author of the Learn to Program website >http://www.freenetpages.co.uk/hp/alan.gauld It was still there three years ago. While debugging some Sun based hardware I tried playing with it after it crashed. Forth was still there. It certainly is useful for a hardware independent bios, but I was making the point it would be good for general purpose. I suspect that it would quickly run up against memory limitations and would go no faster than the machine driving the memory market (with a possible last gasp when Rambus came online). Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the best GUI toolkit in Python,Tkinter,wxPython,QT,GTK?
On Mon, 28 Mar 2005 10:06:14 GMT, Dave Cook <[EMAIL PROTECTED]> wrote: >On 2005-03-27, Tom <[EMAIL PROTECTED]> wrote: > >> 1) Portable to Windows, Unix-like platforms, and the Macintosh; >> 2) Powerful, GUI is very beautiful ; >> 3) Efficiency of development is high; >> >> What's the best, Tkinter, wxPython, QT, GTK or other? > >Don't forget Swing and SWT via Jython. Of course that brings with it all >the joys and sorrows of Java. > >GTK on the Mac (OS X) requires installing and running an X server (an X >server is included on Apple's OS X install discs, but not installed by >default; it can also be downloaded for free from Apple). This may be enough >of an annoyance to turn some users off. I've had success with using GTK on >win32, and it's very standard on Linux systems. > >I'm not sure what the status of QT on OS X is. > >Tkinter still seems viable for things that don't require a lot of complex >controls. Also, it has a very powerful canvas widget. However, it won't >look very good on unix systems (no anti-aliasing, for one thing). > >If you don't need a lot of complex controls, you might consider the embedded >webserver + browser route using CherryPy or Twisted.web + Nevow. > >wxPython seems to have the best cross-platform support among CPython >toolkits, but it never seemed very Pythonic to me. There's a higher-level >package called wax that aims to remedy that. > >Dave Cook PythonCard builds on wxPython (a subset, I believe) and includes a graphic GUI builder. The way it handles the wxPython objects seems pretty pythonic to me, but I can't say I build pretty interface with it. PythonCard seems to like to stick to basics, but also includes a certain ability to get to the rest of wxPython (file/save/message dialogs are pretty easy to include). Note that my only other experience in building GUIs was with visual basic, which seems to have spoiled me. I tried wxPython and Tinker, but could only really get PythonCard to work. Scott Robinson -- http://mail.python.org/mailman/listinfo/python-list
Re: OOP
On Thu, 28 Apr 2005 17:58:47 GMT, Charles Krug <[EMAIL PROTECTED]> wrote: >On 28 Apr 2005 10:34:44 -0700, [EMAIL PROTECTED] ><[EMAIL PROTECTED]> wrote: >> Hey yall, >> I'm new to Python and I love it. Now I can get most of the topics >> covered with the Python tutorials I've read but the one thats just >> stumping me is Object Orientation. I can't get the grasp of it. Does >> anyone know of a good resource that could possibly put things in focus >> for me? Thanks. >> > >"Learning Python" (Lutz/Ascher) has a good discussion of the basics. > >Unfortunately, most of the OOP writings I've read fall into two >catagories: Trivial examples where you say, "But why Bother??" and >examples that you don't understand until you've some OO design under >your belt and can understand what it's all good for. > >Objects are, at the end of the day, data and the accompanying methods. >Once you've read the various tutorials take a stab at converting a >problem you know well into objects. > >You'll get it wrong at first. Most everyone does. Don't sweat it. >Eventually, you'll just "get" it. [Note: this is just the start of an explanation. If you don't understand OOP, just try programming that way (yes, I got it wrong to see my usage of "Wally objects"). This is something I thought of awhile ago, and wondered where I could use it. My background is a hardware guy who first learned spaghetti coding in basic on 8-bits, received the wisdom of modular programming when learning assembler, then much later tried his hand teaching himself python. Those from other backgrounds may be amused at my naivete.] I've been trying to figure out the "Dilbert" view of OOP. My first objects were like C types: class Super_object: pass Consider this the Wally object. Wally=Super_object(): Things get put on his desk: Wally.MeetingActionItems=[1,2,3] And stay there. At first, this seems great. It gives you plenty of desks to store data on. After a while, you might paint yourself into a corner (such as wanting to append to lists, but later wish to hard limit the number of entries, thus needing to change from a list to an overloaded object). This brings the Dilbert object. You can put things on Dilbert's desk, but unlike Wally, he can actually notice the objects, manage them, and do some work on it. Class Dilbert_object: __init__(self): ActionItems=[] def AddItems(self,items): self.ActionItems.append(items) def DoAction(self): return self.ActionItems.pop() Ok, I admit that this just looks like yet another getter and setter. Maybe this is an Asok object and Dilbert would realize that the Boss doesn't remember everything on his desk, so we change it to: Class Dilbert_object: __init__(self): ActionItems=[] def AddItems(self,items): self.ActionItems.append(items) if len(self.ActionItems)>10: self.ActionItems.pop(0) def DoAction(self): return self.ActionItems.pop() Since OOP dogmatists insist that inheritance is vital to OOP, we include the Alice object. Alice can do everything Dilbert can do, and then some. To include Dilbert's skills we simply include Class Alice_object(Dilbert_object): To add new things to the Alice object: Class Alice_object(Dilbert_object): def FistOfDeath(self): import os os._exit(0) The critical thing is that you can now let Dilbert manage your data. That's one of the main reasons for inventing computers anyway, to manage data. So write subprograms (objects) that do your work for you, and work as thanklessly as Dilbert, and then try to concentrate on debugging the big picture. Scott -- http://mail.python.org/mailman/listinfo/python-list
