Re: Developing Commercial Applications in Python
[EMAIL PROTECTED] wrote: > Hello All, > I am trying to convince my client to use Python in his new product. He > is worried about the license issues. Can somebody there to point me any > good commercial applications developed using python ?. The licence > clearly says Python can be used for commercial applications. Is there > any other implications like that of GPL to make the source open ? > Thanks for any help. > eeykay Troika games use Python in their games. It seems you can even get the source .py files for Vampires: Bloodlines :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie inheritance question.
bwobbones wrote: > Hi all, > > I'm a java programmer struggling to come to terms with python - bear > with me! > > I'm trying to subclass a class, and I want to be able to see it's > attributes also. Here are my classes: > > two.py > * > from one import one > > class two(one): > def __init__(self): > print "two" > > def printTestVar(self): > print "testVar: " + str(self.testVar) > * You simply forgot to call the parent __init__. You have to do that explicitely in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help on project, anyone?
Fuzzyman wrote: > > Miki Tebeka wrote: >> Hello Fuzzyman, >> >> > 3) Simple Version Control program for single programmer. A very > simple >> > way of doing version control/releases for small projects with only > a >> > single programmer. [3] >> Subversion (and CVS) are dead simple to install and use. > > I've heard *lots* of people say exactly the opposite. Let's see : # First we prepare the local cvs storage : mkdir ~/cvsroot export CVSROOT=~/cvsroot cvs init # Now we import the existing source code in the cvs "server" cd path/to/project/to/import cvs import ModuleName VendorName START cd ~ cvs co ModuleName And voila, the folder ModuleName is ready for a local cvs usage : cvs update, commit etc... You only need to do once the mkdir ~/cvsroot and the cvs init but don't forget to specify the CVSROOT each time you need to do a cvs import or a cvs checkout. -- http://mail.python.org/mailman/listinfo/python-list
Re: Daylight savings and getmtime
Qvx wrote: > Hello, > > I'we written a simple web deployment program which scans for the > changes made to local copy of web site. Changed files are than > packaged into a zip file and deployed to web server. > > Now here's the catch. Changes are computed using (1) log file from the > last deployment and (2) local file system. Log file contains > datestamps (integers) returned from os.path.getmtime(f) function at > the time of last deployment. So i'm comparing two getmtime() values. > The problem is when Daylight saving kicks in: suddenly all local files > are reported as older than they were at the time of deployment. > > How do I compensate for this? > > Thanks, > Tvrtko Never use the local time, always use GMT ( UTC ) time instead. Since it seems os.path.getmtime already gives UTC time, onemust wonder if your OS isn't broken in some way ;) If you can't solve that problem, then use a simple md5sum of the files instead. md5sum isn't that slow to compute and it gives better results than timestanps. Or use a specialised tool like rsync which does a very good job for that. -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Steven Bethard wrote: > Fuzzyman wrote: > > Cameron Laird wrote: > > [snip..] > > > >>This is a serious issue. > >> > >>It's also one that brings Tcl, mentioned several > >>times in this thread, back into focus. Tcl presents > >>the notion of "safe interpreter", that is, a sub- > >>ordinate virtual machine which can interpret only > >>specific commands. It's a thrillingly powerful and > >>correct solution to the main problem Jeff and others > >>have described. > > > > A better (and of course *vastly* more powerful but unfortunately only > > a dream ;-) is a similarly limited python virutal machine. > > Yeah, I think there are a lot of people out there who would like > something like this, but it's not quite clear how to go about it. If > you search Google Groups, there are a lot of examples of how you can use > Python's object introspection to retrieve "unsafe" functions. > > I wish there was a way to, say, exec something with no builtins and with > import disabled, so you would have to specify all the available > bindings, e.g.: > > exec user_code in dict(ClassA=ClassA, ClassB=ClassB) > > but I suspect that even this wouldn't really solve the problem, because > you can do things like: > > py> class ClassA(object): > ... pass > ... > py> object, = ClassA.__bases__ > py> object > > py> int = object.__subclasses__()[2] > py> int > > > so you can retrieve a lot of the builtins. I don't know how to retrieve > __import__ this way, but as soon as you figure that out, you can then > do pretty much anything you want to. > > Steve Wouldn't it be better to attach to all code objets some kind of access right marker and to create an opcode that calls a function while reducing the access rights ? After all, security would be easier to achieve if you prevented the execution of all the dangerous code rather than trying to hide all the entry points to it. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: PyDev 0.9.0 released
Fabio Zadrozny wrote: > Hi All, > > PyDev - Python IDE (Python development enviroment for Eclipse) version > 0.9.0 has just been released. > > This release supports python 2.4 and has PyLint 0.6 integrated. > Code completion had some improvements too. > > Check the homepage for more details (http://pydev.sourceforge.net/). > > Regards, > > Fabio Zadrozny > -- > Software Developer > ESSS - Engineering Simulation and Scientific Software > www.esss.com.br It looks great but I couldn't get Eclipse to stop using tabs to ident my code, despite the corresponding option in the PyDev preferences window. Is there something I can do for that ? -- http://mail.python.org/mailman/listinfo/python-list
RE: Why doesn't join() call str() on its arguments?
Delaney, Timothy C (Timothy) wrote: > John Roth wrote: > >> result = "".join([str(x) for x in list]) > > As of 2.4, you should use a generator expression here instead (unless > you require backwards-compatibility with 2.3). > > result = ''.join(str(x) for x in iterable) > > Easier to read, more memory-efficient, potentially faster (depending on > performance characteristics of building large lists). > > Tim Delaney Correct me if I'm wrong, but with a real generator expression, join can't know in advance the final size of the resulting string. So, for big strings, the fact that you know in advance the size of the list and of the resulting string could lead to much better performance, even if the memory usage is twice the one of the generator expression. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > André Thieme <[EMAIL PROTECTED]> writes: >> def nif(num, pos, zero, neg): >>if num > 0: >> return pos >>else: >> if num == 0: >>return zero >> else: >>return neg > > def nif(num, pos, zero, neg): >return (neg, zero, pos)[cmp(num, 0)+1] Since we are in one liners, let's be even smarter and do it like that : def nif(num, pos, zero, neg): return (zero, pos, neg)[cmp(num, 0)] ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > Kirk Sluder <[EMAIL PROTECTED]> writes: >> Personally, I've always preferred use the imperative to describe >> basic math rather than the passive. This would seem to map better to >> RPN than infix. > > For writing down complicated, nested expressions too? That's very > unusual. E.g. > > n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ... > > vs. the same thing in Lisp notation, and that's not even so complicated. Yes, infix is better ( and note that Math uses primarly infix notation for common operators ) because you have a clear view of the evaluation tree that way. With prefix or postfix notation, you need to parse the full expression to find what goes to the first parameter of that +, and what goes to the second parameter. I would say that prefix/postfix is somewhat easier to write, but that infix is far far far easier to read. -- http://mail.python.org/mailman/listinfo/python-list
Re: Good Looking UI for a stand alone application
Sandra-24 wrote: > On 12/16/06, The Night Blogger <[EMAIL PROTECTED]> wrote: >> Can someone recommend me a good API for writing a sexy looking (Rich UI >> like WinForms) shrink wrap application > >> My requirement is that the application needs to look as good on Windows >> as on the Apple Mac > > wxPython or something layered on it would be the way to go. I tried all > the popular toolkits (except qt) and nothing else comes close for cross > platform gui work. Don't let people persuade you otherwise, that caused > me a lot of trouble. Well, you should try qt too ;) BTW, does wxWindow/wxPython have something that allows you to switch the OK and Cancel button position according to the current machine GUI guidelines? -- http://mail.python.org/mailman/listinfo/python-list
Re: Good Looking UI for a stand alone application
Vincent Delporte wrote: > On Sun, 17 Dec 2006 09:37:04 +0100, [EMAIL PROTECTED] (Luc Heinrich) > wrote: >>Crossplatform toolkits/frameworks suck. All of them. No exception. If >>you want your app to look *AND* feel great on all platform, abstract the >>core of your application and embed it in platform native GUI code. > > +1. Applications beyond very basic GUI's are better off rewriting the > GUI for each application, while keeping the business logic separate. > Even something as basic as QuickTime sucks on Windows. Read my second reply before reading that part again ;) > I'd be curious to see the source code to Skype: I just installed the > Linux version, and it looks very nice. Maybe it was recompiled with > Kylix. They use QT. Back to read the first part of your post. -- http://mail.python.org/mailman/listinfo/python-list
Re: DOS, UNIX and tabs
Steven D'Aprano wrote: > On Thu, 28 Dec 2006 09:26:28 +0100, Sebastian 'lunar' Wiesner wrote: > >> It is, and especially the problems with tabs shows you, why it is good >> practice to follow the standard in your own code, too... > > I don't know what "problems" with tabs you are talking about. I never have > problems with tabs. *Other people* who choose to use software that doesn't > understand tabs have problems. > > I've spent a lot of time reading both sides of the tabs versus spaces > argument, and I haven't found anything yet that explains why tabs are, in > and of themselves, bad. You gave the reason in your post : because other people who are using software that doesn't understand tabs as YOU expect them to have problems with your code. Tabs aren't a problem at all as long as nobody else than you edit your code. -- http://mail.python.org/mailman/listinfo/python-list
Re: DOS, UNIX and tabs
Felix Benner wrote: > Christophe Cavalaria schrieb: >> Steven D'Aprano wrote: > >> You gave the reason in your post : because other people who are using >> software that doesn't understand tabs as YOU expect them to have problems >> with your code. >> >> Tabs aren't a problem at all as long as nobody else than you edit your >> code. > > Sorry, but that's a silly argument. With the same argument we should > stop using python alltogether since the usual MBA will understand > nothing but VBA. No it isn't. If you have to work with some MBA that understands nothing but VBA, why the hell are you writing Python code in the first place? -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I beat perl at grep-like processing speed?
js wrote:
> Just my curiosity.
> Can python beats perl at speed of grep-like processing?
>
>
> $ wget http://www.gutenberg.org/files/7999/7999-h.zip
> $ unzip 7999-h.zip
> $ cd 7999-h
> $ cat *.htm > bigfile
> $ du -h bigfile
> du -h bigfile
> 8.2M bigfile
>
> -- grep.pl --
> #!/usr/local/bin/perl
> open(F, 'bigfile') or die;
>
> while() {
> s/[\n\r]+$//;
> print "$_\n" if m/destroy/oi;
> }
> -- END --
> -- grep.py --
> #!/usr/bin/env python
> import re
> r = re.compile(r'destroy', re.IGNORECASE)
>
> for s in file('bigfile'):
> if r.search(s): print s.rstrip("\r\n")
> -- END --
>
> $ time perl grep.pl > pl.out; time python grep.py > py.out
> real 0m0.168s
> user 0m0.149s
> sys 0m0.015s
>
> real 0m0.450s
> user 0m0.374s
> sys 0m0.068s
> # I used python2.5 and perl 5.8.6
I'm thankful for the Python version or else, I'd never have guessed what
that code was supposed to do!
Try that :
-- grep.py --
#!/usr/bin/env python
import re
def main():
search = re.compile(r'destroy', re.IGNORECASE).search
for s in file('bigfile'):
if search(s): print s.rstrip("\r\n")
main()
-- END --
--
http://mail.python.org/mailman/listinfo/python-list
Re: python , Boost and straight (but complex) C code
Osiris wrote:
> On Sat, 30 Dec 2006 13:19:28 -0800, Erik Max Francis <[EMAIL PROTECTED]>
> wrote:
>
>>Osiris wrote:
>>
>>> I have these pieces of C-code (NOT C++ !!) I want to call from Python.
>>> I found Boost.
>>> I have MS Visual Studio 2005 with C++.
>>>
>>> is this the idea:
>>> I write the following C source file:
>>>
>>> #include
>>> #include
>>>
>>> namespace { // Avoid cluttering the global namespace.
>>
>>iostream and namespaces are both most definitely C++ features, not C.
>
> yes, but C can be compiled with a C++ compiler, One can put C code in
> C++ source Boost should not complain... should it ?
> Boost text is all about C++.. so... C should not be a problem...
Not all C code can be compiled by a C++ compiler. And anyway, this is
definitively NOT C code.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
Istvan Albert wrote: > On May 19, 3:33 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> >That would be invalid syntax since the third line is an assignment >> > with target identifiers separated only by spaces. >> >> Plus, the identifier starts with a number (even though ６ is not DIGIT >> SIX, but FULLWIDTH DIGIT SIX, it's still of category Nd, and can't >> start an identifier). > > Actually both of these issues point to the real problem with this PEP. > > I knew about them (note that the colon is also missing) alas I > couldn't fix them. > My editor would could not remove a space or add a colon anymore, it > would immediately change the rest of the characters to something > crazy. > > (Of course now someone might feel compelled to state that this is an > editor problem but I digress, the reality is that features need to > adapt to reality, moreso had I used a different editor I'd be still > unable to write these characters). The reality is that the few users who care about having chinese in their code *will* be using an editor that supports them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Christopher Weimann wrote: > On 05/19/2006-07:18AM, Duncan Booth wrote: >> >> My experience of programming with either spaces or tabs has taught me >> that tabs are evil not for themselves, but simply because no matter how >> hard you try they always end up being mixed with spaces. >> > > Swap the word 'tabs' for the word 'spaces' and you get... > > My experience of programming with either tabs or spaces has taught me > that spaces are evil not for themselves, but simply because no matter > how hard you try they always end up being mixed with tabs. > > Which is just as vaild as the un-swapped paragraph. Both versions > express a bias. The first is biased in favor of spaces. The second is > biased in favor of tabs. Neither have any useful content. Mixing is bad > but that fact doesn't favor spaces OR tabs. The difference is that you cannot code without spaces but you can do it without tabs. -- http://mail.python.org/mailman/listinfo/python-list
