Tests are currently failing as pytest has changed how some scopes behave from 7.x to 8.0.

Currently if you want to convert inputs the intended method is to make a post_init function with the fields as arguments and do the conversion and assignment there. For type hinting purposes this means that the fields in the __prefab_post_init__ could be used to define more accurate hints for __init__ if type narrowing is being used. Currently the __init__ type hints are taken directly from the annotations on the class (if present).

For example:

from prefab_classes import prefab
from pathlib import Path

@prefab
class X:
    pth: Path = Path("/usr/bin/python")
    
    def __prefab_post_init__(self, pth: str | Path) -> None:
        self.pth = Path(pth)

would generate code like

from pathlib import Path

class X:
    pth: Path

    def __init__(self, pth: str | Path = Path("/usr/bin/python")) -> None:
        self.__prefab_post_init__(pth)

    ...

    def __prefab_post_init__(self, pth: str | Path) -> None:
        self.pth = Path(pth)
    

As the values are supposed to represent what the object contains rather than what the input value is this should be more accurate for type hinting purposes - at least for the compiled format.

Some features of the actions used for publishing are outdated, these should be updated before releasing the next version (after 0.10.1)

Changes related to typing syntax added a field you need to create a functiondef correctly so all of the AST based implementation tests are failing on 3.12. It looks like this has already been patched to now just create an empty list.

python/cpython#104834

This issue is just to note to retest once beta 2 is available on github actions.

Dataclasses and attrs both have easy ways of creating classes at runtime. This would obviously not work for the compiled versions of classes which are the main feature, but could be useful for dynamically creating dynamic prefabs.

Currently the import hook is part of the prefab_classes module which means in order to import it you first end up importing all of the dynamic machinery. As compiling a prefab now removes the prefab_classes import if it is unnecessary, moving the import hook into a different module could avoid the time importing all of the dynamic code that isn't used.

If init=False xor repr=false or if exclude_field=True on any field in a prefab then the repr will no longer correctly eval back to the original class. In these cases the repr string should no longer attempt to look like a valid call and should instead be a <prefab Name; attrib=value, ...> string.

PyPy only being up to 3.9 was the only reason this project supported Python 3.9 originally.

Some type hints were technically incorrect for python 3.9 but contained in strings to avoid syntax issues, these could now be replaced with regular type hints. (This is mostly the use of | to avoid importing from typing for unions as import typing occurring anywhere in the runtime would be a significant performance hit.)

Despite the theoretical performance benefit of pre-compiled classes, their usage is still awkward. Needing to put the import hook in place and knowing that if another tool compiles the .py files to .pyc it will be ignored (ex: making a pyinstaller bundle) means that they are less useful than hoped.

Due to this I end up not using them myself so I have no real reason to give myself over twice as much work supporting them.

Currently for frozen classes attempting to assign values after instance creation raises a FrozenPrefabError much like the FrozenInstanceError from dataclasses.

This is going to be changed so it raises a plain TypeError instead, much like attempting to assign to a tuple. The reason for this is that currently, in order to do this compiled classes have to import the error in order to raise it - thus adding a slow import of all of the dynamic prefab implementation. A TypeError with an appropriate message seems to fit the pattern of builtins that don't accept assignment so this seems to be the sensible pattern to copy to avoid this import.

Currently descriptor fields won't work correctly. Compiled prefabs will remove any descriptor attributes as they do with all other attributes.

I think these will need to be assigned by an argument to attribute as otherwise compiled prefabs have no way to recognise them.

The implementation will be deferred until I have a use case.

On a quick test to see if prefab_classes have the same issue as dataclasses here:
python/cpython#108611

It turns out that dynamic prefabs handle this as expected, but the AST compiled ones show the same behaviour as dataclasses. Given this is a difference in behaviour of the two implementations this will probably need to be fixed in the compiled form.

I'll add to these as I go, but the goal is to match the external behaviour of both lazy-exec prefab classes and AST generated prefab classes.

• Add type hint method of generation to PrefabClasses
• Convert from class inheritance to decorator

Currently I've used a work-around to the issue of instances of classes as default values but it's definitely more of a work-around than a solution.

The problem can be seen with this example:

from prefab import Attribute, Prefab
from pathlib import Path

class Settings(Prefab):
    pth = Attribute(default=Path('blah'), converter=Path)

x = Settings()

This will throw an exception
NameError: name 'WindowsPath' is not defined

This happens when exec is called on the init function and the signature has WindowsPath('blah') in it, it attempts to evaluate and fails because WindowsPath doesn't exist in the context of the exec.

Currently the hackish solution I've used is explicitly passing the globals dict from where the module is defined.

from prefab import Attribute, Prefab
from pathlib import Path, WindowsPath

class Settings(Prefab):
    _globals = globals()
    pth = Attribute(default=Path('blah'), converter=Path)

x = Settings()

This isn't very satisfying and won't work if the object doesn't have a usable repr.

Demo:

# COMPILE_PREFABS

from prefab_classes import prefab

@prefab(compile_prefab=True, compile_fallback=True)
class X:
    y: str
    y = "test"

Running

x = X()
print(x)

Without the compiler:

X(y='test')

With the compiler:

TypeError: X.__init__() missing 1 required positional argument: 'y'

This is because the compiled version only looks at AnnAssign in this case, it should also check Assign. This will need to check all the assignments in order to avoid differences with the dynamic version.

This has grown beyond just having a readme and so could do with some proper documentation.

Logically it will be largely expected that this will 'do the same thing' as dataclasses where it makes sense. It will be documented if the module is intentionally making different decisions. There are a few obvious features that it makes sense to implement.

Intended compatibility:

• ignore ClassVar typed objects when collecting attributes/fields
• restore match_args for interpreted / add match_args for compiled prefabs
• support empty classes with no attributes.
• Don't overwrite existing dunder methods
• KW_ONLY annotation

ClassVar and KW_ONLY support should be relatively simple.

dataclasses uses an InitVar type to indicate something that should be passed to INIT. I'm not sure that this is the route to follow, but some method of passing variables from init to prefab_post_init could be useful.

I think descriptor fields will either require a specific type annotation or an extra argument to attribute.

Frozen class behaviour might be slightly different to that of dataclasses.

Dataclasses uses a special InitVar annotation to pass values through to __post_init__.

This module is not intending to replicate this behaviour, ClassVar identification is already messy, but is intended to be used as a marker to ignore an attribute.

InitVar is specifically an instruction on how to handle an attribute and so if anything should be an argument to attribute().

The current design idea is to add 1 argument exclude_field to attribute which would exclude the field from all magic methods apart from __init__ and would pass it through to __prefab_post_init__ without assigning it in __init__.

__prefab_pre_init__ and __prefab_post_init__ would also now be able to accept any attribute name as an argument and have it passed from __init__. Arguments used in __prefab_post_init__ will not be assigned in __init__. Any names used in the pre/post init methods that are not valid attributes will raise the appropriate error on construction.

Currently trying to make a slotted class will error as the @prefab decorator does not recognise that the value from the slotted attribute is not a default and so it is interpreted incorrectly.

In v0.11.1 this will be fixed, but it is not particularly useful as you can't use any of the attribute features or set a default value this way, and the attribute must be typed as using attribute() will be interpreted as a class attribute by Python before the @prefab decorator has a chance to modify the class and fail with a ValueError.

In a future version - once compiled prefabs have been removed - I am investigating adding a new syntax to declare prefabs with slots without the downsides of needing to recreate the class from scratch.

My current thinking is the syntax will look something like this:

@prefab
class SlottedPrefab
    __slots__ = PrefabSlots(
        x=attribute(default=42, type=int, doc="doc for x"),
    )

If the class has a __slots__ attribute and the type of the attribute is PrefabSlots it could then use the information there and ignore type hints and attributes for creation.

Once the class has been processed __slots__ will be replaced with a plain dict to allow help(...) to access any docs provided in doc attributes (which currently don't exist).

Runtime types will be placed, but this will probably not play nicely with type checkers. (Although it already doesn't work perfectly).

Initially converters were added as I was replacing attrs but the __init__ code will be simpler with them removed. Their core functionality has been replaced by the __prefab_post_init__ function.