Skip to main content
Shed Skin supports a subset of the Python standard library due to its static compilation model. This page explains what is not supported, why certain features cannot be supported, and suggests alternatives.

Fundamental Limitations

Dynamic Features

Shed Skin requires static typing, which makes many dynamic Python features impossible to support. Not Supported:
Why: These features require runtime type information and interpretation, which defeats the purpose of static compilation. Shed Skin determines all types at compile time. Alternative: Restructure code to use static patterns:

Introspection and Metaprogramming

Not Supported:
Why: Requires runtime introspection capabilities and dynamic type system. Alternative: Use static alternatives:

Unsupported Standard Library Modules

The following categories of standard library modules are not supported:

All Dynamic and Introspection Modules

  • importlib - Dynamic imports
  • inspect - Runtime introspection
  • ast - Abstract syntax trees
  • dis - Bytecode disassembler
  • types - Dynamic type creation
  • typing - Type hints (not needed for Shed Skin)
  • __future__ - Feature flags
Why: These modules exist specifically for Python’s dynamic runtime.

Debugging and Profiling

  • pdb - Python debugger
  • cProfile, profile - Python profiling
  • trace - Execution tracing
  • traceback - Stack trace formatting
Why: Operate on Python bytecode and runtime state. Alternative: Use C++ debugging and profiling tools:

Serialization and Persistence

  • pickle - Object serialization
  • shelve - Persistent dictionary
  • marshal - Internal Python object serialization
  • json - JSON encoding/decoding (not yet supported)
  • xml - XML processing
Why: Require dynamic type information and complex object graphs. Alternative:
  1. Use CSV for simple tabular data (csv module is supported)
  2. Implement custom text-based formats
  3. Use Shed Skin extension module with Python’s pickle:

Threading and Multiprocessing

  • threading - Thread-based parallelism
  • multiprocessing - Process-based parallelism (except when using extension modules)
  • concurrent.futures - High-level parallelism
  • asyncio - Asynchronous I/O
Why: Complex runtime coordination and dynamic scheduling. Alternative:
  1. Use C++ threading directly in custom library code
  2. Use multiprocessing with extension modules:

Network and Web Frameworks

  • urllib, urllib2, urllib3 - URL handling
  • http - HTTP modules
  • requests - HTTP library (third-party)
  • flask, django - Web frameworks
  • email - Email handling
  • smtplib - SMTP protocol
Why: Complex protocol handling, dynamic content, and extensive standard library dependencies. Alternative: Use socket module (partially supported) for low-level networking, or use extension modules with Python network libraries.

GUI Frameworks

  • tkinter - Tk GUI
  • PyQt, PySide - Qt bindings
  • wxPython - wxWidgets bindings
  • pygame - Game development
Why: Large external dependencies and dynamic callback systems. Alternative: Compile performance-critical logic as extension module, use GUI in Python:

Database and ORM

  • sqlite3 - SQLite database
  • mysql - MySQL database
  • psycopg2 - PostgreSQL
  • sqlalchemy - SQL toolkit and ORM
Why: Dynamic query building and complex type mapping. Alternative: Use extension module pattern with database operations in Python.

Partially Supported Modules

Some modules have limited support. Here’s what’s missing:

collections

Not Supported:
  • namedtuple - Named tuple factory (dynamic type creation)
  • Counter - Counting dictionary
  • OrderedDict - Ordered dictionary (regular dict maintains order)
  • ChainMap - Multiple dict views
Alternative:

functools

Not Supported:
  • partial - Partial function application
  • lru_cache - Memoization decorator
  • wraps - Decorator metadata
  • singledispatch - Generic functions
Alternative:

itertools

Not Supported:
  • starmap - Apply function to iterable of tuples
Alternative:

os

Not Supported:
  • os.walk - Directory tree traversal
  • os.popen - Pipe to command
  • os.fork - Process forking
  • Most process management functions
  • Environment variable manipulation (limited)
Supported:
  • Basic file operations: os.remove(), os.rename(), os.listdir()
  • Directory operations: os.mkdir(), os.rmdir(), os.getcwd(), os.chdir()
  • os.path - Fully supported
  • os.system() - Run shell command

sys

Not Supported:
  • sys.modules - Loaded modules
  • sys.path - Module search path
  • Most introspection attributes
  • sys.settrace() - Debug tracing
Supported:
  • sys.argv - Command-line arguments
  • sys.exit() - Exit program
  • sys.stdin/stdout/stderr - Standard streams
  • sys.maxsize - Largest integer

datetime

Status: Partially supported but not well tested Known Issues:
  • May have edge cases with timezone handling
  • Some methods might not work correctly
  • Limited strftime/strptime support
Alternative: Use time module for simple time operations:

Unicode and Text Encoding

Limitation: Currently restricted to 1-byte characters (ASCII, Latin-1). Not Supported:
  • Full Unicode/UTF-8 text processing
  • Multi-byte character encodings
  • unicodedata module
What Works:
  • ASCII text (0-127)
  • Latin-1 text (0-255)
  • Binary data via bytes/bytearray
Alternative:
  1. Process only ASCII/Latin-1 text
  2. Use extension module with Python’s unicode:

Nested Functions and Closures

Not Supported:
Why: Closures require capturing environment and dynamic function objects. Alternative:

Argument Unpacking

Not Supported:
Why: Requires dynamic argument handling. Alternative:

Arbitrary-Size Integers

Limitation: Integers are fixed-size (32-bit, 64-bit, or 128-bit).
Alternative:
  1. Use --int64 or --int128 for larger range
  2. Use float for approximate large numbers
  3. Implement custom bigint if needed (complex)
  4. Use extension module with Python’s int:

Exception Handling Limitations

Limitation: Cannot catch exception by dynamic type
Alternative:

Summary

Best Practices

  1. Compile computational core: Write performance-critical algorithms in Shed Skin-compatible Python
  2. Use extension modules: Keep dynamic/unsupported features in main Python program
  3. Static patterns: Design code with static typing in mind
  4. Test thoroughly: Ensure type inference succeeds on all code paths
  5. Profile first: Verify bottlenecks before porting to Shed Skin

See Also