Skip to content
This repository was archived by the owner on Oct 1, 2025. It is now read-only.
This repository was archived by the owner on Oct 1, 2025. It is now read-only.

dylink's module cache doesn't work under repyportability #28

@aaaaalbert

Description

@aaaaalbert

dylink caches modules that have already been imported in (the same or another) source file so that ciruclar imports don't become a problem, see SeattleTestbed/seattlelib_v2#127. This works as expected when running Repy, but fails under repyportability.
Here's a test case that shows what happens. (I'll make a unit test out of it too). testlib1 just defines an error class, which is imported and raised in a function of testlib2, which in turn is called by the main program, where we try to catch that exception.

# This is testlib1.r2py
class Lib1Error(Exception):
  """The exception we are trying to catch."""

##################################
# This is testlib2.r2py
lib1 = dy_import_module("testlib1.r2py")

def raise_lib1error():
  raise lib1.Lib1Error

################################
# This is the main program
lib1 = dy_import_module("testlib1.r2py") # defines the exception
lib2 = dy_import_module("testlib2.r2py") # raises it

try:
  lib2.raise_lib1error()
except lib1.Lib1Error:
  # Branch taken in Rep
  log("Could catch!\n")
except Exception, e:
  # Branch taken under Repyportability
  log("Nargh, caught", repr(e), "and not", repr(lib1.Lib1Error()))

To check the repyportability behavior, add this to the main program:

from repyportability import *
add_dy_support(locals())

The issue is related to #27 and possibly Seattle's #1422, SeattleTestbed/seattlelib_v2#125, SeattleTestbed/repy_v2#22 (why's that a RepyV2 issue btw?), and SeattleTestbed/repy_v2#55.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions