Re: ANN: Sarge, a library wrapping the subprocess module, has been released.

2012-02-12 Thread Anh Hai Trinh
> 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-

Re: ANN: Sarge, a library wrapping the subprocess module, has been released.

2012-02-12 Thread Anh Hai Trinh
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 littl

Re: ANN: Sarge, a library wrapping the subprocess module, has been released.

2012-02-12 Thread Anh Hai Trinh
> 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

Re: ANN: Sarge, a library wrapping the subprocess module, has been released.

2012-02-12 Thread Anh Hai Trinh
> 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

Re: ANN: Sarge, a library wrapping the subprocess module, has been released.

2012-02-12 Thread Anh Hai Trinh
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

Re: Writing an assembler in Python

2010-02-23 Thread Anh Hai Trinh
On Feb 23, 10:08 am, Lawrence D'Oliveiro wrote: > > Let me suggest an alternative approach: use Python itself as the assembler. > Call routines in your library to output the code. That way you have a > language more powerful than any assembler. > > See for an exa

Re: Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.

2010-02-23 Thread Anh Hai Trinh
On Feb 23, 1:03 pm, "Alf P. Steinbach" wrote: > > Uhm, Paganini... > > As I understand it he invented the "destroy your instruments on stage". :-) > > Cheers, > > - Alf (off-topic) You probably meant Franz Liszt, who regularly broke piano strings. Paganini was also a "rock-star" virtuoso but he d

Re: Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.

2010-02-19 Thread Anh Hai Trinh
On Feb 19, 1:44 pm, Steve Howell wrote: > > > def coroutine(co): > >    def _inner(*args, **kwargs): > >        gen = co(*args, **kwargs) > >        gen.next() > >        return gen > >    return _inner > > > def squares_and_cubes(lst, target): > >    for n in lst: > >        target.send((n * n, n

Re: Overcoming python performance penalty for multicore CPU

2010-02-04 Thread Anh Hai Trinh
On Feb 4, 10:46 am, John Nagle wrote: > >     There's enough intercommunication between the threads working on > a single site that it's a pain to do them as subprocesses. And I > definitely don't want to launch subprocesses for each page; the > Python load time would be worse than the actual work

Re: Is python not good enough?

2010-01-18 Thread Anh Hai Trinh
On Jan 18, 6:03 pm, Phlip wrote: > On Jan 12, 7:09 am, ikuta liu wrote: > > > Go language try to merge low level, hight level and browser language. > > Go uses := for assignment. Except that it doesn't. := is a declaration. s := "foo" is short for var s string = "foo" Cheers, aht -- h

Re: iterators and views of lists

2009-12-19 Thread Anh Hai Trinh
On Dec 20, 12:04 am, Anh Hai Trinh wrote: > chain: > >   sorted(itertools.chain(listagent(x)[::2], listagent(y)[-1:1:-2])) >   [0, 4, 8, 12, 13, 15, 16, 17, 19] > > zip: > >   sorted(itertools.izip(listagent(z)[1::3], listagent(x)[2::3])) >   [(452, 16), (758, 4)

Re: iterators and views of lists

2009-12-19 Thread Anh Hai Trinh
On Dec 19, 5:47 am, Bearophile wrote: > It seems you have missed my post, so here it is, more explicitly: > > http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009... Interestingly, my `listagent` can be used as a lazy iterator and thus using itertools we can compose them just l

Re: iterators and views of lists

2009-12-18 Thread Anh Hai Trinh
On Dec 18, 3:07 am, Brendan Miller wrote: > Well, it doesn't really need to be any slower than a normal list. You > only need to use index and do extra additions because it's in python. > However, if listagent were written in C, you would just have a pointer > into the contents of the original li

Re: iterators and views of lists

2009-12-17 Thread Anh Hai Trinh
> I have a couple of thoughts: > 1. Since [:] by convention already creates a copy, it might violate > people's expectations if that syntax were used. Indeed, listagent returns self on __getitem__[:]. What I meant was this: x = [0, 1, 2, 3, 4, 5, 6, 7] a = listagent(x)[::2] a[:] = listagent

Re: iterators and views of lists

2009-12-16 Thread Anh Hai Trinh
On Dec 16, 2:48 pm, Brendan Miller wrote: > No, that's what I'm getting at... Most of the existing mutating > algorithms in python (sort, reverse) operate over entire collections, > not partial collections delimited by indexes... which would be really > awkward anyway. Ok it can be done! The cod

Re: iterators and views of lists

2009-12-16 Thread Anh Hai Trinh
On Dec 16, 10:39 am, Brendan Miller wrote: > I was trying to reimplement some of the c++ library of generic > algorithms in c++ in python, but I was finding that this is > problematic to do this in a generic way because there isn't any > equivalent of c++'s forward iterators, random access iterato

Re: Seek support for new slice syntax PEP.

2009-12-15 Thread Anh Hai Trinh
>         > from numpy import s_ >         > s_[1:2:3] >         slice(1, 2, 3) >         > s_[1:2:3, ..., 4:5] >         (slice(1, 2, 3), Ellipsis, slice(4, 5, None)) > > Or would it be possible to define "slice" itself so that it implements > __getitem__ and __getslice__? Indeed! Python 2.6.4

which pi formula is given in the decimal module documentation?

2009-12-11 Thread Anh Hai Trinh
I'm just curious which formula for pi is given here: ? def pi(): """Compute Pi to the current precision. >>> print pi() 3.141592653589793238462643383 """ getcontext().prec += 2 # extra digits for intermediate steps three = Decimal(3) # substitute "three=3.0" for reg

Re: A different take on finding primes

2009-11-18 Thread Anh Hai Trinh
> 1) google list of prime numbers > 2) see "Prime numbers list" in the results (number 3 in the results) > 3) click link that leads towww.prime-numbers.org > > I found 455042511 prime numbers in approx 15 seconds. Not bad at all. How about using http://www.sagemath.org/ (written in Python). s

Re: substituting list comprehensions for map()

2009-11-03 Thread Anh Hai Trinh
> Yes, just about any ‘map()’ operation has a corresponding list > comprehension. (Does anyone know of a counter-example, a ‘map()’ > operation that doesn't have a correspondingly simple list > comprehension?) Try turning this into a list comprehension: vectorsum = lambda *args: map(sum, zip(*a

Re: substituting list comprehensions for map()

2009-11-02 Thread Anh Hai Trinh
> Try turning this into a list comprehension: > >   vectorsum = lambda *args: map(sum, zip(*args)) > >   vectorsum([1,2], [3,4], [5,6]) > ->[9, 12] >   vectorsum([1,2], [3,4], [5,6], [7,8]) > ->[16, 20] Nvm, it's actually easy: vectorsum = lambda *args: [sum(i) for i in zip(*args)] -- http://ma

Re: substituting list comprehensions for map()

2009-11-02 Thread Anh Hai Trinh
> On the other hand, list comps using an if clause can't be written as pure > maps. You can do this: > > [func(x) for x in seq if cond(x)] > > filter(cond, map(func, seq)) > > but the second version may use much more temporary memory if seq is huge > and cond very rarely true. You could use ifilte

Re: How about adding slice notation to iterators/generators?

2009-10-26 Thread Anh Hai Trinh
I've written something that is better than you could've imagine. Get it here: It works with anything iterable, no need to alter anything. from itertools import count from stream import item c = count() c >> item[1:10:2] ->[1, 3, 5, 7, 9] c >> item[:5]

Re: Dataflow programming in Python

2009-09-12 Thread Anh Hai Trinh
> Does it have any advantage to generator comprehension? > > import re > mm = mapmethod('strip')        # Is mapmethod something in the stdlib? > pat = re.compile('[Pp]attern') > result = (mm(line) for line in open('log') if pat.search(line)) > > which is also lazy Generator expression accomplishe

Dataflow programming in Python

2009-09-11 Thread Anh Hai Trinh
Hello all, I just want to share with you something that I've worked on recently. It is a library which implements streams -- generalized iterators with a pipelining mechanism and lazy-evaluation to enable data-flow programming in Python. The idea is to be able to take the output of a function tha