I suggested before either porting urpm.pm to python or writing a wrapper around it.
With python-perlmodule, this should be unnecessary. Except that (especially for interactive sessions) it's a little harder to introspect perl data than native python data. For example, calling help() on any kind of perl object fails. Also, which you can index or iterate perl hashes and arrays, printing them directly just gives you something like "<perl pkg=HASH(0x80728f0)>" rather than anything meaningful. And dir() generally gives the perlmodule methods, rather than the underlying perl methods (just like calling dir() on anything with a custom __getattr__). To play with it yoelp(Perl) >>> help(perlmod) urself, try this: >>> from perlmod import Perl >>> urpm = Perl.urpm() >>> urpm.read_config() After this, you can make pretty much the same calls on urpm (and anything you get returned from it) as you could in perl after: > require urpm; > my $urpm = new urpm; > $urpm->read_config(); Or, with perl-Inline-Python, you could write a simple perl wrapper around your python code instead (but there's no interactive interpreter this way, of course): > require urpm; > use Inline Python => <<'END'; > def DoPythonStuff(urpm): > ... > END > my $urpm = new urpm; > DoPythonStuff(urpm); (If anyone wants to play with perlmodule and/or perl-Inline-Python before they appears in contribs, let me know and I'll make RPMs available somewhere else.) So, writing a wrapper might still be useful, but is not necessary--so I won't bother unless anyone else really wants it. (Even better--but a much larger job--would be a tool and/or extension to perlmodule that automatically generated wrappers around perl modules, converting pod into docstrings, maybe even providing dir transparently....)
