dataclasses-json
dataclasses-json copied to clipboard
lidatong
Aliased functions
New functionality to support serializing/deserializing none serializable functions and bound methods. The decorators take an alias name to build maps between the function/method and the alias and the other way around. When the object is serialized the function/method is replaced with the alias. When deserialized the alias is converted back to the function/method.
I kept all of the functionality in a new module (callable_alias) in case we don't decide to merge this. If we do merge this functionality I'd be happy to update init and move the code into core and api as appropriate.
I recognize the problem of non-serializable fields and appreciate your efforts to enhance / improve the library. At the same time I'm worried about library bloat. This seems like an uncommon-enough use-case, especially given this is specific to functions, that I'm hesitant to introduce several new decorators to the API to solve for it.
I would say perhaps it would live better as a separate extension library (or even just as caller code), since the metadata already allows you to plug in arbitrary hooks to encode/decode.
Happy to hear your thoughts
Completely agree. I worked hard to make sure that it didn't require any changes to the library as it exists.
My thought was that we might just add it to the documentation, so people could just cut and paste it if they need it without the over head of another library. It might help someone over a hump with the minimal amount of effort.
On Sun, Aug 25, 2019 at 9:45 AM Charles Li [email protected] wrote:
I recognize the problem of non-serializable fields and appreciate your efforts to enhance / improve the library. At the same time I'm worried about library bloat. This seems like an uncommon-enough use-case, especially given this is specific to functions, that I'm hesitant to introduce several new decorators to the API to solve for it.
I would say perhaps it would live better as a separate extension library (or even just as caller code), since the metadata already allows you to plug in arbitrary hooks to encode/decode.
Happy to hear your thoughts
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lidatong/dataclasses-json/pull/125?email_source=notifications&email_token=AGWDBANKHYSDTCCQANMYZ4DQGKSIVA5CNFSM4IMUFM42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CV7VI#issuecomment-524640213, or mute the thread https://github.com/notifications/unsubscribe-auth/AGWDBAOOOJJGZHIQZOFCERTQGKSIVANCNFSM4IMUFM4Q .
-- Nathan Atkins 720.346.8292 [email protected] linkedin.com/in/nathan-atkins
Let me know if you think having this in the documentation as a section for tips-and-tricks makes sense. I'll rework the pull request to be for only documentation with no impact on the library code or tests.
On Sun, Aug 25, 2019 at 10:19 AM Nathan Atkins [email protected] wrote:
Completely agree. I worked hard to make sure that it didn't require any changes to the library as it exists.
My thought was that we might just add it to the documentation, so people could just cut and paste it if they need it without the over head of another library. It might help someone over a hump with the minimal amount of effort.
On Sun, Aug 25, 2019 at 9:45 AM Charles Li [email protected] wrote:
I recognize the problem of non-serializable fields and appreciate your efforts to enhance / improve the library. At the same time I'm worried about library bloat. This seems like an uncommon-enough use-case, especially given this is specific to functions, that I'm hesitant to introduce several new decorators to the API to solve for it.
I would say perhaps it would live better as a separate extension library (or even just as caller code), since the metadata already allows you to plug in arbitrary hooks to encode/decode.
Happy to hear your thoughts
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lidatong/dataclasses-json/pull/125?email_source=notifications&email_token=AGWDBANKHYSDTCCQANMYZ4DQGKSIVA5CNFSM4IMUFM42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CV7VI#issuecomment-524640213, or mute the thread https://github.com/notifications/unsubscribe-auth/AGWDBAOOOJJGZHIQZOFCERTQGKSIVANCNFSM4IMUFM4Q .
-- Nathan Atkins 720.346.8292 [email protected] linkedin.com/in/nathan-atkins
-- Nathan Atkins 720.346.8292 [email protected] linkedin.com/in/nathan-atkins
Yep I think this would be great as documentation!
On a separate note, I am working on generating web documentation for this library, as I think a single README file is getting too long. Feel free to modify the README for now -- perhaps another section under the "How do I..." heading? Thanks again
Sounds good. I’m out of pocket for a couple of weeks, but I’ll get this when I get back.
Yes, one README is getting to be a bit much.
On Fri, Aug 30, 2019 at 7:02 PM Charles Li [email protected] wrote:
Yep I think this would be great as documentation!
On a separate note, I am working on generating web documentation for this library, as I think a single README file is getting too long. Feel free to modify the README for now -- perhaps another section under the "How do I..." heading? Thanks again
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lidatong/dataclasses-json/pull/125?email_source=notifications&email_token=AGWDBAKSVWXXE7AU7ZS5FLLQHG7JXA5CNFSM4IMUFM42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TCDJI#issuecomment-526786981, or mute the thread https://github.com/notifications/unsubscribe-auth/AGWDBAM7Q73XBICMZX2COBTQHG7JXANCNFSM4IMUFM4Q .
-- Nathan Atkins 720.346.8292 [email protected] linkedin.com/in/nathan-atkins
@nathan5280, please, add examples of usage to ReadMe. Right now they only show API but not the actual demonstrations (i.e., the serialization/deserialization results)
support serializing/deserializing none serializable functions
Well, code is not something you need to serialize, that can just sit on a class as a method and be ready for use when class is instantiated. Moreover, for a pure JSON library as this one, parts that are not fields/get-set properties should be straight ignored. Closing
