Dan Sugalski wrote:
At 2:03 PM -0400 10/11/04, Sam Ruby wrote:
Separate op won't work for Python. Consider:
def f(x,y): return x+y
print f(5,6) # 11
print f("a","b") # ab
Oh, sure it'd work, if you had an ADD_OR_CONCATENATE op with an
appropriate MMD table. :)
Yes, *but" we have to do t
Dan Sugalski wrote:
Separate op won't work for Python. Consider:
def f(x,y): return x+y
print f(5,6) # 11
print f("a","b") # ab
Oh, sure it'd work, if you had an ADD_OR_CONCATENATE op with an
appropriate MMD table. :)
Conceptually, "+" is not an op at all in Python, it is syntatic sugar
At 2:03 PM -0400 10/11/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MM
On Mon, 2004-10-11 at 14:03, Sam Ruby wrote:
> Here's a script that will run in both Python and Perl. It simply will
> return different results.
>
>print "1" + "2","\n",;
>print "45%s8" % "7","\n",;
>print 45 / 7 ,"\n",;
>print ['a','b','c'],"\n",;
>
Dan Sugalski wrote:
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can
introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as a fallback mechanism,
On Sat, 9 Oct 2004, Sam Ruby wrote:
> Inheritance can reduce the combinatorial problem, but it can introduce a
> precendence question. The most interesting case still seems to be:
>
>mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as a fallback mechanism, the foreign
object were cast int
Dan Sugalski wrote:
Are Python specific PMCs the right way to go?
Mostly, yes.
What are the implications of having a PerlString and a PyString? I
guess ultimately we are going to need to decide what to do with things
like:
mmd_lookup(MMD_ADD, PerlString, PyString)
Will the combinatorics inv
Michal <[EMAIL PROTECTED]> wrote:
> When you have the AST handy, it's easier and cleaner
> to just produce a different set of opcodes when you
> know you're in a generator.
Yep.
> Is there any way we could get a temporary --pirate flag that
> did everything --python did EXCEPT for the generator
At 11:59 AM -0400 10/8/04, Sam Ruby wrote:
Leopold Toetsch wrote:
Michal wrote:
Hey all,
Why does --python mode modify the
behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling
for x = iter() ...# iterate
And that's what
On Fri, 8 Oct 2004, Leopold Toetsch wrote:
> Guido is to blame. Python generators/coroutines work like this:
>
>iter = coro() # first time calling
>for x = iter() ...# iterate
>
> And that's what Parrot is doing too with the --python switch. But there
> is more ugliness: Python return
Leopold Toetsch wrote:
Michal wrote:
Hey all,
Why does --python mode modify the
behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling
for x = iter() ...# iterate
And that's what Parrot is doing too with the --python switc
Michal wrote:
Hey all,
Why does --python mode modify the
behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling
for x = iter() ...# iterate
And that's what Parrot is doing too with the --python switch. But there
is more u
Hey all,
Here's a simple hand coded example that
(correctly, AFAIK) prints "ab" in vanilla
parrot, but goes off in an infinite
loop with the --python flag.
Why does --python mode modify the
behaviour of coroutines?
I thought perhaps they were used for
generators or "for...in" iteration, but
th
14 matches
Mail list logo