DOCSLIB.ORG

On Decidability of Nominal Subtyping with Variance

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On Decidability of Nominal Subtyping with Variance University of Pennsylvania ScholarlyCommons Departmental Papers (CIS) Department of Computer & Information Science 9-2006 On Decidability of Nominal Subtyping with Variance Andrew J. Kennedy Microsoft Research Cambridge Benjamin C. Pierce University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/cis_papers Part of the Computer Sciences Commons Recommended Citation Andrew J. Kennedy and Benjamin C. Pierce, "On Decidability of Nominal Subtyping with Variance", . September 2006. Andrew J. Kennedy and Benjamin C. Pierce. On Decidability of Nominal Subtyping with Variance, September 2006. FOOL-WOOD '07. ACM COPYRIGHT NOTICE. Copyright © 2006 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a ee.f Request permissions from Publications Dept., ACM, Inc., fax +1 (212) 869-0481, or [email protected]. This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_papers/671 For more information, please contact [email protected]. On Decidability of Nominal Subtyping with Variance Abstract We investigate the algorithmics of subtyping in the presence of nominal inheritance and variance for generic types, as found in Java 5, Scala 2.0, and the .NET 2.0 Intermediate Language. We prove that the general problem is undecidable and characterize three different decidable fragments. From the latter, we conjecture that undecidability critically depends on the combination of three features that are not found together in any of these languages: contravariant type constructors, class hierarchies in which the set of types reachable from a given type by inheritance and decomposition is not always finite, and class hierarchies in which a type may have multiple supertypes with the same head constructor. These results settle one case of practical interest: subtyping between ground types in the .NET intermediate language is decidable; we conjecture that our proof can also be extended to show full decidability of subtyping in .NET. For Java and Scala, the decidability questions remain open; however, the proofs of our preliminary results introduce a number of novel techniques that we hope may be useful in further attacks on these questions. Disciplines Computer Sciences Comments Andrew J. Kennedy and Benjamin C. Pierce. On Decidability of Nominal Subtyping with Variance, September 2006. FOOL-WOOD '07. ACM COPYRIGHT NOTICE. Copyright © 2006 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept., ACM, Inc., fax +1 (212) 869-0481, or [email protected]. This conference paper is available at ScholarlyCommons: https://repository.upenn.edu/cis_papers/671 On Decidability of Nominal Subtyping with Variance Andrew J. Kennedy Benjamin C. Pierce Microsoft Research Cambridge University of Pennsylvania Abstract 22], and the declaration-site variance of Scala [18], algorithmic subtyping rules have never been presented, and decidability is still We investigate the algorithmics of subtyping in the presence of 1 nominal inheritance and variance for generic types, as found in an open problem. This is the starting point for our investigation. Java 5, Scala 2.0, and the .NET 2.0 Intermediate Language. We Language features Each of these languages supports generic in- prove that the general problem is undecidable and characterize heritance, in which a named class is declared with type parameters three different decidable fragments. From the latter, we conjecture and (multiple) supertypes referencing the type parameters. Here are that undecidability critically depends on the combination of three equivalent definitions in .NET 2.0 IL, C] 2.0, Java 5 and Scala 2.0: features that are not found together in any of these languages: con- .class C<X,Y> extends class D<class E<!X>> // .NET IL travariant type constructors, class hierarchies in which the set of implements class I<!Y> types reachable from a given type by inheritance and decomposi- class C<X,Y> : D<E<X>>, I<Y> // C# tion is not always finite, and class hierarchies in which a type may class C<X,Y> extends D<E<X>> implements I<Y> // Java have multiple supertypes with the same head constructor. class C[X,Y] extends D[E[X]] with I[Y] // Scala These results settle one case of practical interest: subtyping be- A second feature shared by these languages is covariant and tween ground types in the .NET intermediate language is decidable; contravariant subtyping of generic types. Scala 2.0 and .NET 2.0 IL we conjecture that our proof can also be extended to show full de- support declaration-site variance, where the variance behaviour of cidability of subtyping in .NET. For Java and Scala, the decidability type parameters is declared up-front on the declaration of the class; questions remain open; however, the proofs of our preliminary re- this feature is also a strong candidate for a future version of C]. sults introduce a number of novel techniques that we hope may be For example, here are equivalent headers for a contra/co-variant useful in further attacks on these questions. function type in .NET IL, an imaginary future version of C], and Scala: 1. Introduction .class interface Func<-A,+B> // .NET IL The core of the subtype relation in most object-oriented program- interface Func<-A,+B> // C# ?.0 trait Func[-A,+B] // Scala ming languages is nominal, in the sense that basic inclusions be- tween type constructors are explicitly declared by the program- In contrast, Java 5 supports use-site variance, where annotations on mer. However, most languages also support a modicum of struc- the use of a generic type determine its variance behaviour, as in the tural subtyping; for example, array types in Java and C] behave co- cast function below: variantly. More recent designs feature richer structural features—in interface Func<A,B> { B apply(A a); } particular, covariant and contravariant subtyping of constructor pa- class C { } rameters, such as the variance annotations of Scala’s generic types class D extends C { and the wildcard types supported by Java 5. static Func<? super D, ? extends C> Formally, subtyping is typically presented in a declarative cast(Func<? super C, ? extends D> f) { return f; } } style. For many systems, an equivalent syntax-directed presenta- tion is easily derived, and termination of the corresponding sub- Here, the ? extends annotation induces covariant subtyping on type checker is easy to demonstrate. For example, in the case of the type argument, and ? super annotation induces contravariant C] 2.0 and the original “GJ” design for generics in Java [3, 13], subtyping. (In an earlier variance design for Java [14] the annota- it is straightforward to derive an algorithm by building transitivity tions were the more concise + and -.) into the subtyping rules for superclasses and upper bounds and to For all of these languages, decidability of subtyping is an open then prove termination by constructing a measure on subtype judg- problem. The Java 5 design [12, 22] is based on an earlier extension ments that strictly decreases from conclusion to premises in the to Java generics whose decidability is not known [14, §4.1]. A algorithmic rules. core calculus for Scala has been studied recently and type-checking For more sophisticated systems, such as the original use-site and subtyping proved decidable [8], but variance is not supported. variance proposal for Java [14], the wildcard design of Java 5 [12, Finally, an extension to C] 2.0 modeled on variance in .NET IL 2.0 has been studied by the first author and others [10], but without considering generic inheritance in its full generality (in particular, support for multiple instantiation inheritance). Permission to make digital or hard copies of all or part of this work for personal or Contributions We present here a collection of results regard- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation ing the algorithmics of nominal subtyping in the presence of on the first page. To copy otherwise, to republish, to post on servers or to redistribute (declaration-site) variance. First, we show that a general form of to lists, requires prior specific permission and/or a fee. 1 Readers may enjoy attempting to compile the examples in Appendix A Copyright c ACM [to be supplied]. $5.00 using their favorite Java compiler! the problem, where the subtype hierarchy may involve multiple We require that inheritance be acyclic, in the following sense: inheritance from arbitrary supertypes (in particular, from multiple if C <T > <::+ D<U > then C 6= D. In the presence of mixins instances of the same type constructor) is undecidable. Second, we it is not immediately apparent how to check acyclicity for a given show various restricted fragments of the system are decidable: (1) class table: consider, for example, the definitions CX <:: X and a system with only covariant and invariant constructors (no con- D <:: CD.
Load more

Recommended publications
  • “The Church-Turing “Thesis” As a Special Corollary of Gödel's
    “The Church-Turing “Thesis” as a Special Corollary of Gödel’s Completeness Theorem,” in Computability: Turing, Gödel, Church, and Beyond, B. J. Copeland, C. Posy, and O. Shagrir (eds.), MIT Press (Cambridge), 2013, pp. 77-104. Saul A. Kripke This is the published version of the book chapter indicated above, which can be obtained from the publisher at https://mitpress.mit.edu/books/computability. It is reproduced here by permission of the publisher who holds the copyright. © The MIT Press The Church-Turing “ Thesis ” as a Special Corollary of G ö del ’ s 4 Completeness Theorem 1 Saul A. Kripke Traditionally, many writers, following Kleene (1952) , thought of the Church-Turing thesis as unprovable by its nature but having various strong arguments in its favor, including Turing ’ s analysis of human computation. More recently, the beauty, power, and obvious fundamental importance of this analysis — what Turing (1936) calls “ argument I ” — has led some writers to give an almost exclusive emphasis on this argument as the unique justification for the Church-Turing thesis. In this chapter I advocate an alternative justification, essentially presupposed by Turing himself in what he calls “ argument II. ” The idea is that computation is a special form of math- ematical deduction. Assuming the steps of the deduction can be stated in a first- order language, the Church-Turing thesis follows as a special case of G ö del ’ s completeness theorem (first-order algorithm theorem). I propose this idea as an alternative foundation for the Church-Turing thesis, both for human and machine computation. Clearly the relevant assumptions are justified for computations pres- ently known.
    [Show full text]
  • Church's Thesis and the Conceptual Analysis of Computability
    Church’s Thesis and the Conceptual Analysis of Computability Michael Rescorla Abstract: Church’s thesis asserts that a number-theoretic function is intuitively computable if and only if it is recursive. A related thesis asserts that Turing’s work yields a conceptual analysis of the intuitive notion of numerical computability. I endorse Church’s thesis, but I argue against the related thesis. I argue that purported conceptual analyses based upon Turing’s work involve a subtle but persistent circularity. Turing machines manipulate syntactic entities. To specify which number-theoretic function a Turing machine computes, we must correlate these syntactic entities with numbers. I argue that, in providing this correlation, we must demand that the correlation itself be computable. Otherwise, the Turing machine will compute uncomputable functions. But if we presuppose the intuitive notion of a computable relation between syntactic entities and numbers, then our analysis of computability is circular.1 §1. Turing machines and number-theoretic functions A Turing machine manipulates syntactic entities: strings consisting of strokes and blanks. I restrict attention to Turing machines that possess two key properties. First, the machine eventually halts when supplied with an input of finitely many adjacent strokes. Second, when the 1 I am greatly indebted to helpful feedback from two anonymous referees from this journal, as well as from: C. Anthony Anderson, Adam Elga, Kevin Falvey, Warren Goldfarb, Richard Heck, Peter Koellner, Oystein Linnebo, Charles Parsons, Gualtiero Piccinini, and Stewart Shapiro. I received extremely helpful comments when I presented earlier versions of this paper at the UCLA Philosophy of Mathematics Workshop, especially from Joseph Almog, D.
    [Show full text]
  • Typescript Language Specification
    TypeScript Language Specification Version 1.8 January, 2016 Microsoft is making this Specification available under the Open Web Foundation Final Specification Agreement Version 1.0 ("OWF 1.0") as of October 1, 2012. The OWF 1.0 is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. TypeScript is a trademark of Microsoft Corporation. Table of Contents 1 Introduction ................................................................................................................................................................................... 1 1.1 Ambient Declarations ..................................................................................................................................................... 3 1.2 Function Types .................................................................................................................................................................. 3 1.3 Object Types ...................................................................................................................................................................... 4 1.4 Structural Subtyping ....................................................................................................................................................... 6 1.5 Contextual Typing ............................................................................................................................................................ 7 1.6 Classes .................................................................................................................................................................................
    [Show full text]
  • A System of Constructor Classes: Overloading and Implicit Higher-Order Polymorphism
    A system of constructor classes: overloading and implicit higher-order polymorphism Mark P. Jones Yale University, Department of Computer Science, P.O. Box 2158 Yale Station, New Haven, CT 06520-2158. [email protected] Abstract range of other data types, as illustrated by the following examples: This paper describes a flexible type system which combines overloading and higher-order polymorphism in an implicitly data Tree a = Leaf a | Tree a :ˆ: Tree a typed language using a system of constructor classes – a mapTree :: (a → b) → (Tree a → Tree b) natural generalization of type classes in Haskell. mapTree f (Leaf x) = Leaf (f x) We present a wide range of examples which demonstrate mapTree f (l :ˆ: r) = mapTree f l :ˆ: mapTree f r the usefulness of such a system. In particular, we show how data Opt a = Just a | Nothing constructor classes can be used to support the use of monads mapOpt :: (a → b) → (Opt a → Opt b) in a functional language. mapOpt f (Just x) = Just (f x) The underlying type system permits higher-order polymor- mapOpt f Nothing = Nothing phism but retains many of many of the attractive features that have made the use of Hindley/Milner type systems so Each of these functions has a similar type to that of the popular. In particular, there is an effective algorithm which original map and also satisfies the functor laws given above. can be used to calculate principal types without the need for With this in mind, it seems a shame that we have to use explicit type or kind annotations.
    [Show full text]
  • Python Programming
    Python Programming Wikibooks.org June 22, 2012 On the 28th of April 2012 the contents of the English as well as German Wikibooks and Wikipedia projects were licensed under Creative Commons Attribution-ShareAlike 3.0 Unported license. An URI to this license is given in the list of figures on page 149. If this document is a derived work from the contents of one of these projects and the content was still licensed by the project under this license at the time of derivation this document has to be licensed under the same, a similar or a compatible license, as stated in section 4b of the license. The list of contributors is included in chapter Contributors on page 143. The licenses GPL, LGPL and GFDL are included in chapter Licenses on page 153, since this book and/or parts of it may or may not be licensed under one or more of these licenses, and thus require inclusion of these licenses. The licenses of the figures are given in the list of figures on page 149. This PDF was generated by the LATEX typesetting software. The LATEX source code is included as an attachment (source.7z.txt) in this PDF file. To extract the source from the PDF file, we recommend the use of http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ utility or clicking the paper clip attachment symbol on the lower left of your PDF Viewer, selecting Save Attachment. After extracting it from the PDF file you have to rename it to source.7z. To uncompress the resulting archive we recommend the use of http://www.7-zip.org/.
    [Show full text]
  • Bundled Fragments of First-Order Modal Logic: (Un)Decidability
    Bundled Fragments of First-Order Modal Logic: (Un)Decidability Anantha Padmanabha Institute of Mathematical Sciences, HBNI, Chennai, India [email protected] https://orcid.org/0000-0002-4265-5772 R Ramanujam Institute of Mathematical Sciences, HBNI, Chennai, India [email protected] Yanjing Wang Department of Philosophy, Peking University, Beijing, China [email protected] Abstract Quantified modal logic is notorious for being undecidable, with very few known decidable frag- ments such as the monodic ones. For instance, even the two-variable fragment over unary predic- ates is undecidable. In this paper, we study a particular fragment, namely the bundled fragment, where a first-order quantifier is always followed by a modality when occurring in the formula, inspired by the proposal of [15] in the context of non-standard epistemic logics of know-what, know-how, know-why, and so on. As always with quantified modal logics, it makes a significant difference whether the domain stays the same across possible worlds. In particular, we show that the predicate logic with the bundle ∀ alone is undecidable over constant domain interpretations, even with only monadic predicates, whereas having the ∃ bundle instead gives us a decidable logic. On the other hand, over increasing domain interpretations, we get decidability with both ∀ and ∃ bundles with unrestricted predicates, where we obtain tableau based procedures that run in PSPACE. We further show that the ∃ bundle cannot distinguish between constant domain and variable domain interpretations. 2012 ACM Subject Classification Theory of computation → Modal and temporal logics Keywords and phrases First-order modal logic, decidability, bundled fragments Digital Object Identifier 10.4230/LIPIcs.FSTTCS.2018.43 Acknowledgements We thank the reviewers for the insightful and helpful comments.
    [Show full text]
  • Refinement Types for ML
    Refinement Types for ML Tim Freeman Frank Pfenning [email protected] [email protected] School of Computer Science School of Computer Science Carnegie Mellon University Carnegie Mellon University Pittsburgh, Pennsylvania 15213-3890 Pittsburgh, Pennsylvania 15213-3890 Abstract tended to the full Standard ML language. To see the opportunity to improve ML’s type system, We describe a refinement of ML’s type system allow- consider the following function which returns the last ing the specification of recursively defined subtypes of cons cell in a list: user-defined datatypes. The resulting system of refine- ment types preserves desirable properties of ML such as datatype α list = nil | cons of α * α list decidability of type inference, while at the same time fun lastcons (last as cons(hd,nil)) = last allowing more errors to be detected at compile-time. | lastcons (cons(hd,tl)) = lastcons tl The type system combines abstract interpretation with We know that this function will be undefined when ideas from the intersection type discipline, but remains called on an empty list, so we would like to obtain a closely tied to ML in that refinement types are given type error at compile-time when lastcons is called with only to programs which are already well-typed in ML. an argument of nil. Using refinement types this can be achieved, thus preventing runtime errors which could be 1 Introduction caught at compile-time. Similarly, we would like to be able to write code such as Standard ML [MTH90] is a practical programming lan- case lastcons y of guage with higher-order functions, polymorphic types, cons(x,nil) => print x and a well-developed module system.
    [Show full text]
  • Lecture Slides
    Outline Meta-Classes Guy Wiener Introduction AOP Classes Generation 1 Introduction Meta-Classes in Python Logging 2 Meta-Classes in Python Delegation Meta-Classes vs. Traditional OOP 3 Meta-Classes vs. Traditional OOP Outline Meta-Classes Guy Wiener Introduction AOP Classes Generation 1 Introduction Meta-Classes in Python Logging 2 Meta-Classes in Python Delegation Meta-Classes vs. Traditional OOP 3 Meta-Classes vs. Traditional OOP What is Meta-Programming? Meta-Classes Definition Guy Wiener Meta-Program A program that: Introduction AOP Classes One of its inputs is a program Generation (possibly itself) Meta-Classes in Python Its output is a program Logging Delegation Meta-Classes vs. Traditional OOP Meta-Programs Nowadays Meta-Classes Guy Wiener Introduction AOP Classes Generation Compilers Meta-Classes in Python Code Generators Logging Delegation Model-Driven Development Meta-Classes vs. Traditional Templates OOP Syntactic macros (Lisp-like) Meta-Classes The Problem With Static Programming Meta-Classes Guy Wiener Introduction AOP Classes Generation Meta-Classes How to share features between classes and class hierarchies? in Python Logging Share static attributes Delegation Meta-Classes Force classes to adhere to the same protocol vs. Traditional OOP Share code between similar methods Meta-Classes Meta-Classes Guy Wiener Introduction AOP Classes Definition Generation Meta-Classes in Python Meta-Class A class that creates classes Logging Delegation Objects that are instances of the same class Meta-Classes share the same behavior vs. Traditional OOP Classes that are instances of the same meta-class share the same behavior Meta-Classes Meta-Classes Guy Wiener Introduction AOP Classes Definition Generation Meta-Classes in Python Meta-Class A class that creates classes Logging Delegation Objects that are instances of the same class Meta-Classes share the same behavior vs.
    [Show full text]
  • Soundness of Workflow Nets: Classification
    DOI 10.1007/s00165-010-0161-4 The Author(s) © 2010. This article is published with open access at Springerlink.com Formal Aspects Formal Aspects of Computing (2011) 23: 333–363 of Computing Soundness of workflow nets: classification, decidability, and analysis W. M. P. van der Aalst1,2,K.M.vanHee1, A. H. M. ter Hofstede1,2,N.Sidorova1, H. M. W. Verbeek1, M. Voorhoeve1 andM.T.Wynn2 1 Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands. E-mail: [email protected] 2 Queensland University of Technology, Brisbane, Australia Abstract. Workflow nets, a particular class of Petri nets, have become one of the standard ways to model and analyze workflows. Typically, they are used as an abstraction of the workflow that is used to check the so-called soundness property. This property guarantees the absence of livelocks, deadlocks, and other anomalies that can be detected without domain knowledge. Several authors have proposed alternative notions of soundness and have suggested to use more expressive languages, e.g., models with cancellations or priorities. This paper provides an overview of the different notions of soundness and investigates these in the presence of different extensions of workflow nets. We will show that the eight soundness notions described in the literature are decidable for workflow nets. However, most extensions will make all of these notions undecidable. These new results show the theoretical limits of workflow verification. Moreover, we discuss some of the analysis approaches described in the literature. Keywords: Petri nets, Decidability, Workflow nets, Reset nets, Soundness, Verification 1.
    [Show full text]
  • Undecidable Problems: a Sampler
    UNDECIDABLE PROBLEMS: A SAMPLER BJORN POONEN Abstract. After discussing two senses in which the notion of undecidability is used, we present a survey of undecidable decision problems arising in various branches of mathemat- ics. 1. Introduction The goal of this survey article is to demonstrate that undecidable decision problems arise naturally in many branches of mathematics. The criterion for selection of a problem in this survey is simply that the author finds it entertaining! We do not pretend that our list of undecidable problems is complete in any sense. And some of the problems we consider turn out to be decidable or to have unknown decidability status. For another survey of undecidable problems, see [Dav77]. 2. Two notions of undecidability There are two common settings in which one speaks of undecidability: 1. Independence from axioms: A single statement is called undecidable if neither it nor its negation can be deduced using the rules of logic from the set of axioms being used. (Example: The continuum hypothesis, that there is no cardinal number @0 strictly between @0 and 2 , is undecidable in the ZFC axiom system, assuming that ZFC itself is consistent [G¨od40,Coh63, Coh64].) The first examples of statements independent of a \natural" axiom system were constructed by K. G¨odel[G¨od31]. 2. Decision problem: A family of problems with YES/NO answers is called unde- cidable if there is no algorithm that terminates with the correct answer for every problem in the family. (Example: Hilbert's tenth problem, to decide whether a mul- tivariable polynomial equation with integer coefficients has a solution in integers, is undecidable [Mat70].) Remark 2.1.
    [Show full text]
  • The ∀∃ Theory of D(≤,∨, ) Is Undecidable
    The ∀∃ theory of D(≤, ∨,0 ) is undecidable Richard A. Shore∗ Theodore A. Slaman† Department of Mathematics Department of Mathematics Cornell University University of California, Berkeley Ithaca NY 14853 Berkeley CA 94720 May 16, 2005 Abstract We prove that the two quantifier theory of the Turing degrees with order, join and jump is undecidable. 1 Introduction Our interest here is in the structure D of all the Turing degrees but much of the motivation and setting is shared by work on other degree structures as well. In particular, Miller, Nies and Shore [2004] provides an undecidability result for the r.e. degrees R at the two quantifier level with added function symbols as we do here for D. To set the stage, we begin then with an adaptation of the introduction from that paper including statements of some of its results and so discuss R, the r.e. degrees and D(≤ 00), the degrees below 00 as well. A major theme in the study of degree structures of all types has been the question of the decidability or undecidability of their theories. This is a natural and fundamental question that is an important goal in the analysis of these structures. It also serves as a guide and organizational principle for the development of construction techniques and algebraic information about the structures. A decision procedure implies (and requires) a full understanding and control of the first order properties of a structure. Undecidability results typically require and imply some measure of complexity and coding in the struc- ture. Once a structure has been proven undecidable, it is natural to try to determine both the extent and source of the complexity.
    [Show full text]
  • Marshmallow-Annotations Documentation Release 2.4.1
    marshmallow-annotations Documentation Release 2.4.1 Alec Nikolas Reiter Jan 28, 2021 Contents 1 Installation 3 2 Content 5 Index 21 i ii marshmallow-annotations Documentation, Release 2.4.1 Version 2.4.1 (Change Log) marshmallow-annotations allows you to create marshmallow schema from classes with annotations on them: # music.py from typing import List class Album: id: int name: str def __init__(self, id: int, name: str): self.id= id self.name= name class Artist: id: int name: str albums: List[Album] def __init__(self, id: int, name: str, albums: List[Album]): self.id= id self.name= name self.albums= albums # schema.py from marshmallow_annotations import AnnotationSchema from.music import Album, Artist class AlbumScheme(AnnotationSchema): class Meta: target= Album register_as_scheme= True class ArtistScheme(AnnotationSchema): class Meta: target= Artist register_as_scheme= True scheme= ArtistScheme() scheme.dump( Artist( id=1, name="Abominable Putridity", albums=[ Album( id=1, name="The Anomalies of Artificial Origin" ) ] ) ) #{ # "albums": [ #{ # "id": 1, (continues on next page) Contents 1 marshmallow-annotations Documentation, Release 2.4.1 (continued from previous page) # "name": "The Anomalies of Artificial Origin" #} # ], # "id": 1, # "name": "Abominable Putridity" #} 2 Contents CHAPTER 1 Installation marshmallow-annotations is available on pypi and installable with: pip install marshmallow-annotations marshmallow-annotations supports Python 3.6+ and marshmallow 2.x.x Note: If you are install marshmallow-annotations outside of a virtual environment, consider installing with pip install --user marshmallow-annotations rather than using sudo or adminstrator privileges to avoid installing it into your system Python. 3 marshmallow-annotations Documentation, Release 2.4.1 4 Chapter 1. Installation CHAPTER 2 Content 2.1 Quickstart This guide will walk you through the basics of using marshmallow-annotations.
    [Show full text]