It looks like you want a script that will take two edges into account, the vertices of the selected edge should move towards the closest vertices of the active edge.
In code that looks like:
# This example assumes we have a mesh object in edit-mode
from bmesh.types import BMEdge
me = obj.data
bm = bmesh.from_edit_mesh(me)
# get active edge or return early
active = bm.select_history.active
if not isinstance(active, BMEdge):
print("no active edge")
av1, av2 = active.verts[:]
# get first selected edge that isn't active
selected = None
for e in bm.edges:
if e.select and not e.hide:
if e == active:
selected = e
if not selected:
print('no selected verts beyond the active edge')
# find corresponding verts and move
sv1, sv2 = selected.verts[:]
if (sv1.co - av1.co).length <= (sv1.co - av2.co).length:
sv1.co = av1.co.copy()
sv2.co = av2.co.copy()
sv1.co = av2.co.copy()
sv2.co = av1.co.copy()
d = 0.0001
bmesh.ops.remove_doubles(bm, verts=[sv1, sv2, av1, av2], dist=d)
# Show the updates in the viewport
# and recalculate n-gon tessellation.
# Get the active mesh
obj = bpy.context.edit_object
it could have many improvements; like dropping the remove doubles step and updating the edge vertex indices to use the existing indices of the active edge instead.
However -- there is an obvious potentially false assumption here, the corresponding vertex on the other edge might not be the closest. A solution is to make the geometry less ambiguous or improve the closest point search algorithm
for example the scenario on the left is obvious to us, and the algorithm will get it right because the corresponding vertices on both edges are nearer their counterparts.
The example on the right will get results depending on which vertex index is looked at first, can work, can fail. Obvious to our eyes, not so obvious to the dumb algorithm I use above.