dave, i don't think adam is on this list. you probably need to reply in JIRA. i do think however, that the issue is open to discussion on this list if others would like to comment. We do intend to release gremlin-python as "experimental" with the intent of gathering feedback for a final release on 3.3.0.
On Tue, Aug 30, 2016 at 2:54 PM, David Brown <davebs...@gmail.com> wrote: > @aholmber - Regarding naming, while methods typically have lowercase > names separated with underscores, PEP 8 does suggest that "mixedCase > is allowed only in contexts where that's already the prevailing > style". While this typically refers to backwards compatibility, you > see mixed case in libraries that provide bridges to other > languages...the example that comes to mind is PyObjC. I wonder if this > is an example where using mixed case is acceptable in order to give > gremlin-python the same "feel" as gremlin...thoughts? > > On Tue, Aug 30, 2016 at 2:39 PM, stephen mallette (JIRA) > <j...@apache.org> wrote: > > > > [ https://issues.apache.org/jira/browse/TINKERPOP-1278? > page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel& > focusedCommentId=15449778#comment-15449778 ] > > > > stephen mallette commented on TINKERPOP-1278: > > --------------------------------------------- > > > > [~stamhankar999] thanks for your thoughts on the testing aspects of > things. i think we have some work to do before we can call the testing > model completely settled for all GLVs. I suspect some changes will occur. I > think we need a good mix of native tests as well as those that can be > executed via the process suites. We will try to come to a full > understanding of that model for 3.3.x. > > > > [~aholmber] i remember your commit comment. i think that happened when > [~okram] was away on vacation. since he wrote the code generation stuff for > that, perhaps he'd be best to have a look and address your concerns. > > > >> Implement Gremlin-Python and general purpose language variant test > infrastructure > >> ------------------------------------------------------------ > --------------------- > >> > >> Key: TINKERPOP-1278 > >> URL: https://issues.apache.org/ > jira/browse/TINKERPOP-1278 > >> Project: TinkerPop > >> Issue Type: Improvement > >> Components: language-variant > >> Affects Versions: 3.2.0-incubating > >> Reporter: Marko A. Rodriguez > >> Assignee: Marko A. Rodriguez > >> Fix For: 3.2.2 > >> > >> > >> As discussed on dev@... > >> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin > language variants. It would be cool if these were: > >> * Python (Mark Henderson) > >> * PHP ([~PommeVerte]) > >> * Ruby (?[~okram]) > >> I think each of these should be generated using the reflection-model > presented in http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/ > gremlin-language-variants/. Moreover, on every {{mvn clean install}}, the > code for these variants is generated. > >> Given the desire to separate language variants from language drivers, I > think that a language driver for each variant above should be "plugable." > Moreover, we should provide one driver implementation for each -- simple > GremlinServer REST. > >> {code} > >> gremlin-variants/ > >> gremlin-ruby/ > >> gremlin_ruby.rb > >> gremlin_ruby_rest_driver.rb > >> gremlin-php/ > >> Gremlin_PHP.php > >> Gremlin_PHP_REST_Driver.php > >> gremlin-python/ > >> gremlin-python.py > >> gremlin-python-rest-driver.py > >> {code} > >> Next, each variant implementation should be testable. This is PAINFUL > if we have to implement each {{g_V_out_repeatXasXaXX}} test case in > {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to > convert all those tests from Gremlin-Java to the respective host language? > However, even if we do that, we still have the problem of how to test the > returned results. > >> I think what we should test the returned results using the JVM. For > instance, JRuby, Jython, JPHP (does it exist?). If we do this, we will save > ourselves a massive headache. All we have to do is create a > {{GraphProvider}} that uses {{TinkerGraph}} and whose {{TraversalSource}} > is some sort of wrapper around reflection-generated Ruby (e.g.). > >> {code} > >> g.V.out_e("knows") // returns a Ruby iterator > >> {code} > >> That Ruby iterator should be converted to a Java iterator and then the > {{ProcessXXXSuite}} can verify the results. > >> With this, most everything is reflectively constructed. > >> {code} > >> gremlin_ruby.rb // generated via Java reflection > >> gremlin_ruby_rest_driver.rb // manually coded > >> match_test.rb // generated via RegEx transducer > >> has_test.rb // generated via RegEx transducer > >> ... > >> RubyGraphProvider.java // manually coded > >> RubyProcessStandardSuite.java // manually coded > >> RubyProcessComputerSuite.java // manually coded > >> {code} > >> Thus, the testing data flow would be: > >> {code} > >> MatchTest.Traversals.java --transducer-> match_test.rb > >> match-test.rb --REST--> GremlinServer > >> GremlinServer --GraphSON-->match-test.rb > >> GraphSON --JRuby/GraphSONReader-->Java objects > >> Java objects --JRuby-->MatchTest.java > >> {code} > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.3.4#6332) > > > > -- > David M. Brown > R.A. CulturePlex Lab, Western University >
