Xdis

Latest version: v6.1.0

Safety actively analyzes 629052 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 5 of 19

4.5.1

====================================

* Fix bug in marshal for 3.8+ (include posonlyargcount)
* Go over stack effects from 2.5 to 3.4 using and idea from Maynard
* Expand stack-effect testing

4.5.0

==============================

* `stack_effects()` checked against Python 3.4+ is now in place.
* Added `stack_effects()` function to `std.py` since this is part of the API
* `cross_xdis.py` file/module now has `dis.py` functions split off from `bytecode.py`
* `Instructions` class is in its own module too.
* Python 2.7.18 added into magics.

Incompatibility with earlier versions:

Note: as a result of the reorganization, exported functions from
bytecode are now in cross_dis. However, functions are exported from
the top-level so use that and there will be no disruption in the
future. For example `from xdis import iscode, instruction_size,
code_info`.

4.4.0

===============================

Incompatibility: `load_module()` and `load_module_from_file_object()` now return a couple more parameters: is_pypy, and the sip_hash value when that is available. The timestamp and file_size returned on these functions is now None when they aren't available. Previously timestamp had been 0.

* --asm option fixes
* Show sip hash in 3.7+ when that is used
* Handle PEP 552 bytecode-file variations more properly
* Detect more intermediate Python versions in `load_code_from_file_object()`
* 3.8+ posonlyargcount in assembly... rename Kw-only field to Keyword-only
* Add 3.5 canonic bytecode version Marshal `dumps()`
* convert from byte() to str() in dumps() when needed in 3.x
* to_native() convert to bytes from string when needed in 3.x.
* clean up loading code by using float version values rather than magic values

4.3.2

Portable Code Type
------------------

A portable version of types.CodeType was rewritten, to make it

* easier to use
* and catch more errors
* more complete in tracking Python `types.CodeType` changes
* simpler in implementation by using type inheretence
* more general

Previously getting bytecode read from a bytecode file or from a code object requiring knowing a lot about the Python version of the code type and of the currently running interpreter. That is gone now.

Use `codeType2Portable()` to turn a native `types.CodeType` or a structure read in from a bytecode file into a portable code type. The portable code type allows fields to be mutated, and is more flexible in the kinds of datatypes it allows.

For example lists of thing like `co_consts`, or `varnames` can be Python lists as well as tuples. The line number table is stored as a dictionary mapping of address to bytecode offset rather than as a compressed structure. Bytecode can either be a string (which is advantageous if you are running Python before 3.x) or a sequence of bytes which is the datatype of a code object for 3.x.

However, when you need a `type.CodeType` that can be `eval()`'d by the Python interpreter you are running, use the `to_native()` method on the portable code type returned. It will compress and encode the line number table, and turn lists into tuples and convert other datatypes to the right type as needed.

If you have a *complete* `types.Codetype` structure for a particular Python version whether, it is the one the current Python interpreter is using or not, use the `to_portable()` function, and it will figure out based on the version parameter supplied (or use the current Python interpreter version if none supplieed), which particlar portable code type is the right one.

If on the other hand, you have a number of code-type fields which may be incomplete, but still want to work with something that has code-type characteristics while not worrying about which fields are required and their exact proper datatypes, use the `CodeTypeUnion` structure.

Internally, we use OO inheritance to reduce the amount of duplicate code. The `load_code_internal()` function from `unmarshal.py` is now a lot shorter and cleaner as a result of this reorganization.

New Portable Code Methods, Modules and Classes

* Python 3.8-ish `replace()` method has been added to the portable code types
* Portable code type classes `Code13`, `Code15` have been added to more precisely distinguish Python 1.3 and 1.5 code types. The other portable code classes are `Code2`, `Code3`, and `Code38`.
* the to_native() converts a portable code type into a native code type
* the `decode_lineno_tab()` method on portable code types from Python 1.5 on decompresses the Python encode line number table into a dictionary mapping offset to line number.


Incompatibility
---------------

The module `xdis.code` has been remamed to `xdis.codetype` and with that the function `iscode()` moved as well. In previous versions to use `iscode()` you might import it from `xdis.code`; now simply import it from `xdis`. In general function that had been imported from a module under `xdis` can now be imported simply from `xdis`.

The classes `Compat3Code` and function `code2compat()` and `code3compat()` have been removed. `Compat2Code` is still around for dropbox 2.5, but that is deprecated and will be removed when I can figure out how to remove it from dropbox 2.5.

Other Changes
-------------

CI testing for older testing has been fixed now that 2.7 is even more deprecated.

4.3.1

===================================

Fix bug in handling Python 3.8 bytecode.

Sadly, I inadvertently wasn't testing 3.8 bytecode before. That's now fixed too.

4.3.0

===================================

Page 5 of 19

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.