List view
I want to support parsing of a specified (non-dataclass) type, i.e. without using the `model.from_dict` or `fromdict` serializer functions. For example, a `list` of dataclass instances, or a `Union` of one or more dataclass types, would all be valid and custom data types that we would want to de-serialize from. Note that `pydantic` already offers something which does exactly what I'm envisioning, using a helper function named `parse_obj_as`: https://pydantic-docs.helpmanual.io/usage/models/#parsing-data-into-a-specified-type
Overdue by 3 year(s)•Due by April 30, 2022I want to add an option on `JSONWizard` sub-classes to return the prettified representation of the `__repr__` method of an instance that the `dataclasses` module implements - i.e. using the builtin `pprint.pformat` function - in lieu of our default `__str__` implementation, which prints the prettified JSON string representation of the instance. So essentially, instead of printing a prettified JSON string representation of an instance when `print(obj)` is invoked, I want it to pretty print the *Python object* representation of the object. Which would be the same as if the user explicitly called `pprint.pprint(obj)`, but here the benefit is that we can abstract this away from the user, so they only need to call `print(obj)` to get the desired result in this case.
Overdue by 4 year(s)•Due by January 25, 2022This is something that libraries like `pydantic` offer, after a fashion, but I don't want to get too into the wilds and offer this on a per-field basis; rather, I want to add class-specific support for automatically ensuring that all fields are have validators and/or type converters attached to them. For example, maybe a class decorator approach like `@validation_wizard` could work -- note the name is just a rough draft now, so it's likely it'll change in the actual implementation; this decorator could also take additional parameters (all optional), such as perhaps restricting the fields to validate - maybe a param called `exclude` would contain a list of dataclass fields to skip validation on. But more to the point: what would this decorator actually *do*? Well, my thought process would be to have it first determine a list of dataclass fields (i.e. ones that are actually fields, and not associated with properties for example) and then proceed to have it override the class's `__setattr__` method. In this new method, it'll type check the value against the annotated type for the field; if the type doesn't match, it can either raise an error, *or* it can neatly corral the type into the annotated type for the field; for example, if an annotated type for a field `isActive` is `bool`, a string value of "yes" will be correctly cast to `True`, and the field `isActive` correctly set to that bool value, for example. This is actually exactly the same as how the de-serialization process is performed using `to_dict` or `asdict`. However, the benefit here is that we can ensure field assignment is type safe, so for example if we have an annotated `str` field, trying to assign a `list` value to it would ostensibly raise a validation error, or something like that. As mentioned, I don't want to get too deep into the weeds and start offering per-field validation, as there are already libraries out there that handle this exact use case, such as `pydantic` for example.
Overdue by 3 year(s)•Due by May 1, 2022Setting again a tentative due date, as I'm not sure when I'll be able to look into this. Basically, I want to enable the usage of custom serializer hooks, which will be run for example *before* or *after* `from_dict` is called, or similarly *before* or *after* `to_dict` is called. I want to allow these to be specified on per-class basis, and also the dataclass does *not* necessarily have to extend from `JSONWizard`, it can be just a regular dataclass. This is important, because we need to support the use case where a class inheritance model is not used. The methods that a class would be able to implement, can be named something like `__pre_load__` and `__pre_dump__`, or perhaps a bit more explicit, like `__pre_deserialize__`, though that's kind of verbose; inevitably the method names are subject to change, and it might even be worth it to brainstorm to formalize on the ideal method names that we want to suggest that classes implement. I also want to provide a Mixin class, something like `SerializerHookMixIn`, that is an abstract class (ABC) defining the methods which we are looking for, just to aid in type hinting and autocompletion for IDEs, and also so that we can enable awareness of each method signature and any return types, for example.
Overdue by 3 year(s)•Due by April 15, 2022Setting a tentative due date, as I'm not sure how much effort this will take. Essentially, I want to enable the usage of *per-field* serializer and deserializer functions. In theory, this means that user-defined transform functions can be specified for each dataclass field, for fine-grained control over how that field value is de-serialized to a Python type, and how it is serialized to a JSON string or a `dict` object. For example, the below syntax (mostly pseudocode) is the simplest usage of what I had in mind: ```python3 @dataclass class Example: my_date_field: datetime = field(metadata={ 'deserializer': lambda o: datetime.strptime("my-date-time-format"), 'serializer': lambda o: o.strftime("my-target-date-string-format"), }) ``` Though, I also had another idea, which is to create custom functions like `Serializer` and `Deserializer`, and let the user specify them as an extra in the `Annotated[T, extra...]` form, as shown below: ```python3 from typing_extensions import Annotated @dataclass class Example: my_date_field: Annotated[ datetime, Serializer( lambda o: o.strftime("my-target-date-string-format")) ] ```
Overdue by 3 year(s)•Due by March 1, 2022I want to support nested traversal in a JSON object with deserialization, and possibly the same thing in serialization too, if time allows. To better illustrate, consider a JSON object such as below: ```json { "key": "value", "contacts": [ {"address": "1234 My Street", "name": "John Smith"} ] } ``` It would be cool if we can map the first `contacts[0].address` to a dataclass field, like `resident_address`. I have below dataclass schema with an idea how that could work: ```python3 from dataclasses import dataclass from dataclass_wizard import json_field, json_key from typing_extensions import Annotated @dataclass class MyClass: resident_address: str = json_field(path='contacts.0.address') resident_name: Annotated[str, json_key(path=lambda x: x['contacts'][0]['name'])] ```
Overdue by 3 year(s)•Due by March 1, 2022I want to add support for `dotenv` and Environment Variables in the Dataclass Wizard library. Perhaps a model class like `EnvWizard` can be created - and regular classes can then extend from this base class, allowing the defined environment variables to be retrieved from the environment, and used as normal variables in Python code.
Overdue by 3 year(s)•Due by February 15, 2022Setting a tentative due date, because I have no idea when I'm going to be able to get around to this. Basically, there's a way I figured out to improve deserialization performance - perhaps slightly, I'm not too sure how huge an impact it would actually have. This way involves updating the `__call__` method in all load Parsers to return a function rather than returning an object. Right now, the `__call__` method is called each time on deserialization, so it'll do a few unoptimized things like accessing instance attributes each time. I'd like to update `__call__` to be a method that returns an inner function. If there's any instance attributes we need to access, put them on the top level inside `__call__`, but outside of the inner function. That way these attributes are treated as globals (essentially) and the access pattern will be much faster. As a result, deserialization process will definitely be faster by (hopefully no small) margin.
Overdue by 3 year(s)•Due by February 1, 2022