[
https://issues.apache.org/jira/browse/PIG-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845420#action_12845420
]
Woody Anderson commented on PIG-928:
------------------------------------
@julien
have read over your code.
1. schema parsing: yup, i much prefer re-using the parser, i wasn't able to
find that impl, but should have been more diligent in looking for it.
2. i love the outputSchema decorator pattern that you use.
3. code via a .py file vs. string literal in the constructor. The .py file is a
definite win when dealing with encoding issues (quotes, newlines etc). It's
also a cleaner way to import larger blocks of code, and works for jython files
etc. that are used indirectly etc. The constructor pattern is still supported
in my approach, i just use it exclusively for lambda functions.
4. the pyObjToObj code is simpler in your approach, but limits the integration
flexibility. i.e. you explicitly tie tuple:tuple, list:bag. Also, it's not
clear how well this would handle sequences and iterators etc. I personally
prefer using the schema to disambiguate the conversion, so that existing python
code can be used to generate bags/tuples etc. via the schema rather than having
to convert python objects using wrapper code.
5. the outputSchema logic is nice (as i said in #2, i love the decorator
thing), but the schema should be cached if it is not a function. If it's a
function, then the ref should be cached. This is particularly important if
you're using the schema to inform the python -> pig data coercion.
6. as i said in prev comments, the scope of the interpreter is important. If
you have two different UDFs that you want to share any state (such as
counters), then a shared interpreter is a good idea. There are also memory
gains from sharing etc. In general, i think you rarely want a distinct
interpreter, and as such it should be possible, but not the default.
Anyway, thanks for attaching the submission, i think there are lots of great
ideas in your project. It makes me wish i'd known about it sooner, parsing the
pig schema system was not a fun day, though i guess i did learn a bit from it.
The decorator thing is lovely. I'll probably borrow those and produce a tighter
jython and scripting harness at some point.
Overall, i'm still firmly in the multi-language camp, but i think this provides
nice improvements for a jython impl, and can clearly still swallow whatever
language support pig introduces for anyone who wants to drive pig from python.
So i think it should still be useful as a standalone project/harness.
> UDFs in scripting languages
> ---------------------------
>
> Key: PIG-928
> URL: https://issues.apache.org/jira/browse/PIG-928
> Project: Pig
> Issue Type: New Feature
> Reporter: Alan Gates
> Attachments: package.zip, pyg.tgz, scripting.tgz, scripting.tgz
>
>
> It should be possible to write UDFs in scripting languages such as python,
> ruby, etc. This frees users from needing to compile Java, generate a jar,
> etc. It also opens Pig to programmers who prefer scripting languages over
> Java.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
