Re: Python does not play well with others

Dennis Lee Bieber wrote: > Uhm... Unless something has happened that I don't know about, isn't > C# a M$ specific product? Mono? Regards Stephan -- http://mail.python.org/mailman/listinfo/python-list

Re: Python does not play well with others

Harry George wrote: > Perl - excellent modules and bindings for just about everything you ... > Java - a world of its own. They reinvent the wheel instead of linking ... > PHP - are we talking web scripts or serious programs? Are you doing ... > C - the portable assembler. Solid, trusted, tunab

Re: What am I supposed to do with an egg?!

Sebastian 'lunar' Wiesner wrote: > Morpheus <[EMAIL PROTECTED]> wrote > >> So, what am I supposed to do here now? > > That's easy: Breed it... Since two days I'm fighting with myself not to make this joke. Thanks for relieving me... Regards Stephan -- http://mail.python.org/mailman/listinfo/

Re: Coding standards without control?

Soni Bergraj wrote: > editormt wrote: >> A majority of the participating organisations have coding standards... >> and a majority does not control them ;o) What is the situation at your >> location? Does this lack of control really hurt? > > """A Foolish Consistency is the Hobgoblin of Little Min

Re: Ruby/Python/REXX as a MUCK scripting language

Tony Belding wrote: > Is this practical? I'm thinking of Ruby or Python for this, if they > can meet the requirements. Python had a sandbox module, but is was discarded because of security problems. If you want it working on MacOS, you may also have a look at Tcl, which has a long tradition on

Re: Secure Python

Steve Holden wrote: > Anyone with an interest in secure Python should take a look at what > Brett Cannon is doing in his postgraduate work. There have been some > discussions on the python-dev list. Can you some links to his work, the discussions or some other starting point? Stephan -- http:/

Re: Secure Python

Hendrik van Rooyen wrote: > I seem to recall previous discussion on this group about a thing called > the bastion module, > and that it was deprecated. Not sure if it has any relevance. Never heard about it, maybe it's worth a look for the OP. Stephan -- http://mail.python.org/mailman/listin

Re: Secure Python

Paul Boddie wrote: >> implement the lowest common denominator of all OS resource managements to >> be platform independent, which is a strong requirement, IMO. > > I think I understand what you intend to say here: that some kind of > Python sandbox relying on operating system facilities can only

Re: Secure Python

timmy <"timothy at open-networks.net"> wrote: >> count and limit the number of evaluation steps allowed for untrusted >> script or methods in untrusted script as well as to limit the recursion >> depth or memory to be allocated. > > idunno sounds like a lot of trouble to engineer a solution that

Re: Secure Python

timmy <"timothy at open-networks.net"> wrote: This sub-thread starts to become a flame-war, isn't it? Calm down, both of you... No need to fight, when only some ideas for a technical question are requested. > as posted before, linux kernel limit. > > then you and your users can go as crazy as yo

Re: Secure Python

Fredrik Tolf wrote: > If this doesn't work, might there be some other way to run untrusted > code that I haven't thought of (apart from using O/S-specific stuff like > SECCOMD, of course). There was a module called rexec which tries to give you a restricted environment for executing code. But it

Re: Searching for a module to generate GUI events

Paul Boddie wrote: > Searching for "Python GUI testing" on Google gave this as the first > result: Thank you very much, this looks very promissing to me. Seems to be a very usefull skill, if one is able to type the right words at the google prompt. Think, I should learn that some day... ;-) Step

Re: Searching for a module to generate GUI events

utabintarbo wrote: > http://pywinauto.pbwiki.com/ for Win32 Thanks for the hint, looks usable. But it seems, there's nothing for X11 and MacOSX. I didn't thought, that the problem would be so unusual... Stephan -- http://mail.python.org/mailman/listinfo/python-list

Re: Cactching Stdout

Dennis Lee Bieber wrote: >> popen...is this what I need? How can I use them? It is very important >> for me that I could take the output in real-time. >> Thanks for the help! >> Massi > > That's going to be difficult... popen and pipes work when one > process starts another INDEPENDENT process.

Searching for a module to generate GUI events

Hello I'm searching for a Python Module which is able to generate GUI events on different platforms (at least X11 and Windows, MacOSX would be nice), but without being a GUI toolkit itself. So PyTk is not a choice, because I need to use it, to control GUIs of other Programs. I want to generate Mou

Re: Tracing the execution of scripts?

"Michael B. Trausch" <"mike$#at^&nospam!%trauschus"> wrote: > Basically, is there something that will log every line of Python code > executed, in its order of execution, to a text file so that I can see > what is (or isn't) happening that I am expecting? Python itself can do this for you. A __VE

Re: Where is Python in the scheme of things?

Magnus Lycka wrote: ... > I'd suggest that the OP look at the Wikipedia page in Unix > Philosophy. Read about Gancarz tenets, and replace shell scripts > with Python. (Of course, Python offers more elaborate communication > than pipes.) I'd also the link to Joel Spolsky's Biculturalism > article,

Re: Making sure script only runs once instance at a time.

Hari Sekhon wrote: > I have written a script and I would like to ensure that the script is > never run more than once at any given time. > > What is the best way of testing and exiting if there is another version > of this script running somewhere on this machine? > > I guess what I'm asking is

Re: Trying to run an external program

Brant Sears wrote: > Any ideas on what I might do to troubleshoot this? As other stated out, you are using the wrong module. Try: >>> import os >>> p=os.popen('dir') >>> for l in p: ... print l ... --- OUTPUT OF DIR HERE --- >>> p.close() The return value of close is the return value of the c

Re: Issues with Installer written in Python for Linux

[EMAIL PROTECTED] wrote: > I am undertaking writing an installer for a software package using > Python. It is exclusively for Linux. Because this is an installer and > has to run on numerous Linux distros, it is presenting some unique > challenges. I had the same problem to solve as you, and I ho

Re: #!/usr/bin/python or #!/usr/bin/env python?

Erik Max Francis wrote: > The problem is that there are endless ways to do that, and figuring out > all the cases makes `file` an sh interpreter, not the magic number > detector it's supposed to be. It makes it into a pattern-matcher, not an interpreter. But that it is already. But right, there

Re: #!/usr/bin/python or #!/usr/bin/env python?

Tobias Brox wrote: > This is very off-topic, Sorry for starting that... > but if it's fairly common to begin tcl-scripts > as a /bin/sh-file with "exec tcl" at one of the first lines, I think > "file" ought to be able to recognize it. > > """exec" python is clearly an obscure hack not used by

Re: #!/usr/bin/python or #!/usr/bin/env python?

ZeD wrote: > print "Hello, world" > $ file test.py > test.py: Bourne shell script text executable Yes, the same happens with all Tcl-Scripts. I like to see this as a bug in "file", not in the scripting... Stephan -- http://mail.python.org/mailman/listinfo/python-list

Re: #!/usr/bin/python or #!/usr/bin/env python?

Erik Max Francis wrote: >>> #!/bin/sh >>> """exec" python "$0" "$@""" >> >> Wow, cool... I like that! > > Only someone genuinely fond of the Tcl hack could ... True, I admit, I'm a Tcl-Addict... But I really love Python too for many reasons. But I miss features and tricks in both languages that

Re: #!/usr/bin/python or #!/usr/bin/env python?

Michał Bartoszkiewicz wrote: > #!/bin/sh > """exec" python "$0" "$@""" Wow, cool... I like that! Stephan -- http://mail.python.org/mailman/listinfo/python-list

Re: #!/usr/bin/python or #!/usr/bin/env python?

> Always prefer to use env over a hardcoded path, because that hardcoded > path will invariably be wrong. (Yes, for those about to nitpick, it's > conceivable that env might be somewhere other than /usr/bin. However, > that is very rare and results in a no-win situations regardless of the > issue