The short answer, as given in jonrsharpe's comment:
no, per The import statement - Python Language Reference. What you already have is correct.
There is a bit of a workaround though:
Step 1: Provide a module, in which you organize your imports (call it e.g. my_imports.py):
# Contents of `my_imports.py` import dataclasses from dataclasses import dataclass import json
Step 2: Use from my_imports import …:
from my_imports import dataclasses, dataclass, json @dataclass class Point3D: x: int y: int z: int def to_json(self) -> str: return json.dumps(dataclasses.asdict(self)) print(Point3D(x=1, y=2, z=3).to_json())
I cannot judge whether that makes sense for you or whether this appears too contrived. A potential use case that I could think of would be having very explicit control over what imports are allowed in a project: Provide all of them via my_imports in a single place; then, in all other modules, ensure that only my_imports is imported.
Two side notes: First, @dataclass is probably not as unambiguous as you might think; Pydantic, for example, provides an alternative implementation. Second, in dataclasses, contrary to SymPy, it's asdict(), not as_dict().
Finally, as an afterthought: I guess the described workaround is somewhat similar to what is called "barrel files" in JavaScript (I was not aware of these, since I am not really familiar with JavaScript). Googling also revealed, however, that barrel files seem to be a somewhat controversial concept, the first few hits containing phrases such as The Benefits and Disadvantages of Using Barrel Files and Please Stop Using Barrel Files. The latter finding makes me want to emphasize: I just wanted to show a possible workaround, I am not sure if it is really meaningful in any scenario in general (including the one that I mentioned) or in your use case in particular.
