anchor.diff:  [[using-python-and-remoteconnection]]
   === Using Python and RemoteConnection
   
  -image:python-logo.png[width=125,float=left,link="https://www.python.org/"] The JVM is a powerful piece of technology that has, over the years,
  -become a meeting ground for developers from numerous language communities. However, not all applications will use the JVM.
  -Given that Apache TinkerPop is a Java-framework, there must be a way for two different virtual machines to communicate
  -traversals and their results. This section presents the second Gremlin language variant implementation model which does just that.
  +image:python-logo.png[width=125,float=left,link="https://www.python.org/"] The JVM is a powerful piece of technology
  +that has, over the years, become a meeting ground for developers from numerous language communities. However, not all
  +applications will use the JVM. Given that Apache TinkerPop is a Java-framework, there must be a way for two different
  +virtual machines to communicate traversals and their results. This section presents the second Gremlin language
  +variant implementation model which does just that.
   
   NOTE: Apache TinkerPop is a JVM-based graph computing framework. Most graph databases and processors today are built
   on the JVM. This makes it easy for these graph system providers to implement Apache TinkerPop. However, TinkerPop is more
  
positive.code: the reflection-based source code generation technique presented. This method ensures that the language
  variant is always in sync with the corresponding Apache TinkerPop Gremlin-Java release version. Moreover, it reduces
  the chance of missing methods or creating poorly implemented methods. While Gremlin is simple, there are nearly 200
  steps in `GraphTraversal`. As such, mechanical means of host language embedding are strongly advised.
  
negative.code: 
  2. `GraphTraversalSource` (**compiler**): This is the typical `g` reference. A `GraphTraversalSource` maintains the
  `withXXX()`-strategy methods as well as the "traversal spawn"-methods such as `V()`, `E()`, `addV()`, etc.
  A traversal source's registered `TraversalStrategies` determine how the submitted traversal will be ultimately
  evaluated.
  
  3. `GraphTraversal` (**function composition**): A graph traversal maintains the computational steps such as `out()`, `groupCount()`,
  `match()`, etc. This fluent interface supports method chaining and thus, a linear "left-to-right" representation of a
  traversal/query.
  
  4. `__` (**function nesting**) : The anonymous traversal class is used for passing a traversal as an argument to a
  parent step. For example, in `repeat(__.out())`, `__.out()` is an anonymous traversal passed to the traversal parent
  `repeat()`. Anonymous traversals enable the "top-to-bottom" representation of a traversal.
  
  5. `Bytecode` (**language agnostic encoding**): The source and traversal steps and their arguments are encoded in a
  language agnostic representation called Gremlin bytecode. This representation is a nested list of the form
  `[step,[args*]]*`.
  
  Both `GraphTraversal` and `__` define the structure of the Gremlin language. Gremlin is a _two-dimensional language_
  supporting linear, nested step sequences. Historically, many Gremlin language variants have failed to make the
  distinctions above clear and in doing so, either complicate their implementations or yield variants that are not in
  1-to-1 correspondence with Gremlin-Java. By keeping these concepts clear when designing a language variant, the
  construction of the Gremlin bytecode representation is easy.
  
  IMPORTANT: The term "Gremlin-Java" denotes the language that is defined by `GraphTraversalSource`, `GraphTraversal`,
  and `__`. These three classes exist in `org.apache.tinkerpop.gremlin.process.traversal.dsl.graph` and form the
  definitive representation of the Gremlin traversal language.
  
  == Gremlin-Jython and Gremlin-Python
  
  