Skip to content

Module vs. Namespace #6

Open
Open
@L33T

Description

@L33T

Currently, the Python project defines modules based on the core sub-projects (arch, common, compiler, symex) which requires specific module imports (or wildcard) to obtain classes. (i.e. from vtil.arch import basic_block)

This does not follow the core project where "imports" are usually inside the main namespace (VTIL). For example, basic_block is accessible from the main namespace (vtil::basic_block) unlike the python project which puts the class inside vtil::arch::basic_block virtually.

This is arguably good for organizing the massive projects into submodules, but can result in a confusing import perspective. Take the following for example:

from vtil.arch import routine, basic_block
from vtil.common import tagged_order

def on_block(bbl: basic_block) -> tagged_order:
  print(bbl)
  return tagged_order.obreak

rtn = routine.load('./hello_world.vtil')
rtn.for_each(on_block)

tagged_order is actually vtil::enumerator::tagged_order which is contained inside the common project and requires to be explicitly imported, instead of being inside the global vtil namespace.

The following is considered:

from vtil import routine, basic_block, tagged_order

def on_block(bbl: basic_block) -> tagged_order:
  print(bbl)
  return tagged_order.obreak

rtn = routine.load('./hello_world.vtil')
rtn.for_each(on_block)

And the submodules would be replaced with explicitly nested namespaces inside the vtil namespace. (i.e. debugger, symbolic)

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requesthelp wantedExtra attention is neededquestionFurther information is requested

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions