You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this patch, we test for `dataclasses` which use `field`'s to define
default values. Originally, we thought that there are issues with data
classes in general due to the issue #288, but it turned out that the
order of decorators matters (``dataclass`` first).
We tested everything, and documented the order of the decorators
accordingly.
Fixes#288.
Copy file name to clipboardExpand all lines: docs/source/known_issues.rst
+27-3Lines changed: 27 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,16 @@
1
1
Known Issues
2
2
============
3
-
**Integration with ``help()``**. We wanted to include the contracts in the output of ``help()``. Unfortunately,
3
+
Integration with ``help()``
4
+
---------------------------
5
+
6
+
We wanted to include the contracts in the output of ``help()``. Unfortunately,
4
7
``help()`` renders the ``__doc__`` of the class and not of the instance. For functions, this is the class
5
8
"function" which you can not inherit from. See this
6
9
`discussion on python-ideas <https://groups.google.com/forum/#!topic/python-ideas/c9ntrVuh6WE>`_ for more details.
7
10
8
-
**Defining contracts outside of decorators**. We need to inspect the source code of the condition and error lambdas to
11
+
Defining contracts outside of decorators
12
+
----------------------------------------
13
+
We need to inspect the source code of the condition and error lambdas to
9
14
generate the violation message and infer the error type in the documentation, respectively. ``inspect.getsource(.)``
10
15
is broken on lambdas defined in decorators in Python 3.5.2+ (see
11
16
`this bug report <https://bugs.python.org/issue21217>`_). We circumvented this bug by using ``inspect.findsource(.)``,
@@ -35,7 +40,9 @@ However, we haven't faced a situation in the code base where we would do somethi
35
40
whether this is a big issue. As long as decorators are directly applied to functions and classes, everything
36
41
worked fine on our code base.
37
42
38
-
**`*args` and `**kwargs`**. Since handling variable number of positional and/or keyword arguments requires complex
43
+
``*args`` and ``**kwargs``
44
+
--------------------------
45
+
Since handling variable number of positional and/or keyword arguments requires complex
39
46
logic and entails many edge cases (in particular in relation to how the arguments from the actual call are resolved and
40
47
passed to the contract), we did not implement it. These special cases also impose changes that need to propagate to
41
48
rendering the violation messages and related tools such as pyicontract-lint and sphinx-icontract. This is a substantial
@@ -44,3 +51,20 @@ effort and needs to be prioritized accordingly.
44
51
Before we spend a large amount of time on this feature, please give us a signal through
45
52
`the issue 147 <https://github.com/Parquery/icontract/issues/147>`_ and describe your concrete use case and its
46
53
relevance. If there is enough feedback from the users, we will of course consider implementing it.
54
+
55
+
``dataclasses``
56
+
---------------
57
+
When you define contracts for `dataclasses <https://docs.python.org/3/library/dataclasses.html>`_, make sure you define the contracts *after* decorating the class with ``@dataclass`` decorator:
58
+
59
+
.. code-block:: python
60
+
61
+
>>>import icontract
62
+
>>>import dataclasses
63
+
64
+
>>>@icontract.invariant(lambdaself: self.x >0)
65
+
...@dataclasses.dataclass
66
+
...classFoo:
67
+
... x: int= dataclasses.field(default=42)
68
+
69
+
70
+
This is necessary as we can not re-decorate the methods that ``dataclass`` decorator inserts.
0 commit comments