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 switch. But there is more ugliness: Python returns "None" if the generator is left through the end and a StopIteration is thrown (which you have to catch).

That's all really messy and needs definitely some cleanup. OTOH it was the most straight forward translation of Python bytecode.

Ultimately, it would be nice if Perl and Python could run on the same instance of Parrot; this would be pretty much be precluded by switches such as this.


Pirate is currently running with --python due to a number of Python specific behaviors introduced into a number of PMCs. I'd like to revert back to running without the --python switch... which would require the introduction of a number of new Python PMCs.

The number of such PMCs would likely number between one and three dozen. I'm quite willing to work on a series of patches that adds these in stages.

Are Python specific PMCs the right way to go? 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 involved in adding a new language overwhelm us?

Should the Python specific behavior be removed from the Perl PMCs? If so, when?

- Sam Ruby

Reply via email to