Check PY2EXE, PYREX and PSYChO. I must use these packages
to relase commercial products with my own dll in c.
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 17, 1:49 pm, Jean-Michel Pichavant
wrote:
> I can't use it though, I'm still using a vintage 2.5 version :-/
That's a shame. I chose 2.6 as a baseline for this package, because I
need it to work on Python 2.x and 3.x with the same code base and
minimal work, and that meant supporting Unic
Vinay Sajip wrote:
Sarge, a cross-platform library which wraps the subprocess module in
the standard library, has been released.
What does it do?
Sarge tries to make interfacing with external programs from your
Python applications easier than just using subprocess alone.
Sarge
On Feb 13, 7:08 am, Anh Hai Trinh wrote:
> > Objection! Does the defense REALLY expect this court to believe that
> > he can testify as to how MOST members of the Python community would or
> > would not favor bash over Python? And IF they do in fact prefer bash,
> > is this display of haughty arro
On Feb 13, 3:57 am, Anh Hai Trinh wrote:
>
> I don't disagree with it. But the solution is really easy, just call 'sh' and
> pass it a string!
>
> >>> from extproc import sh
> >>> n = int(sh(“ls /etc –1 | wc –l”))
>
> No parser needed written!
>
> Yes there is a danger of argument parsing and gl
> Objection! Does the defense REALLY expect this court to believe that
> he can testify as to how MOST members of the Python community would or
> would not favor bash over Python? And IF they do in fact prefer bash,
> is this display of haughty arrogance nothing more than a hastily
> stuffed straw-
On Feb 12, 2:13 pm, Vinay Sajip wrote:
> wc(ls("/etc", "-1"), "-l")
>
> is not as readable as
>
> call(“ls /etc –1 | wc –l”)
And i agree!
I remember a case where i was forced to use an idiotic API for
creating inputbox dialogs. Something like this:
prompts = ['Height', 'Width', 'Color']
values
On Feb 12, 9:35 am, Anh Hai Trinh wrote:
> > It's not hard for the user
>
> I think most users like to use Python, or they'd use Bash. I think people
> prefer not another language that is different from both, and having little
> benefits. My own opinion of course.
Objection! Does the defense RE
On Monday, February 13, 2012 3:13:17 AM UTC+7, Vinay Sajip wrote:
> On Feb 12, 3:35 pm, Anh Hai Trinh wrote:
>
> > I think most users like to use Python, or they'd use Bash. I think people
> > prefer not another language that is different from both, and having little
> > benefits. My own opinio
On Feb 12, 4:19 pm, Anh Hai Trinh wrote:
> If you use threads and call fork(), you'll almost guaranteed to face with
> deadlocks. Perhaps not in a particular piece of code, but some others.
> Perhaps not on your laptop, but on the production machine with different
> kernels. Like most race con
On Feb 12, 3:35 pm, Anh Hai Trinh wrote:
> I think most users like to use Python, or they'd use Bash. I think people
> prefer not another language that is different from both, and having little
> benefits. My own opinion of course.
>
I have looked at pbs and clom: they Pythonify calls to exter
> For a careful impl of fork-exec with threads, see
> http://golang.org/src/pkg/syscall/exec_unix.go
I forgot to mention that this impl is indeed "correct" only because you cannot
start thread or call fork() directly in the Go language, other than use
goroutines and the ForkExec() function impl
> It's not hard for the user
I think most users like to use Python, or they'd use Bash. I think people
prefer not another language that is different from both, and having little
benefits. My own opinion of course.
Re. threads & fork():
http://www.linuxprogrammingblog.com/threads-and-fork-think
On Feb 12, 9:41 am, Anh Hai Trinh wrote:
> Having written something with similar purpose
> (https://github.com/aht/extproc), here are my comments:
>
> * Having command parsed from a string is complicated. Why not just have an
> OOP API to construct commands?
It's not hard for the user, and less
Having written something with similar purpose (https://github.com/aht/extproc),
here are my comments:
* Having command parsed from a string is complicated. Why not just have an OOP
API to construct commands? extproc does this, but you opted to write a
recursive descent parser. I'm sure it's fun
On Fri, Feb 10, 2012 at 2:28 PM, Vinay Sajip wrote:
> Sarge, a cross-platform library which wraps the subprocess module in
> the standard library, has been released.
>
> What does it do?
>
>
> Sarge tries to make interfacing with external programs from your
> Python applications e
Sarge, a cross-platform library which wraps the subprocess module in
the standard library, has been released.
What does it do?
Sarge tries to make interfacing with external programs from your
Python applications easier than just using subprocess alone.
Sarge offers the following
17 matches
Mail list logo
