# PEP 713: Callable Modules

**URL:** <https://discuss.python.org/t/pep-713-callable-modules/26127>\
**Category:** PEPs\
**Created:** [April 23, 2023, 8:31pm UTC](https://discuss.python.org/t/pep-713-callable-modules/26127 "2023-04-23T20:31:03Z")\
**Posts on this page:** 1\
**Showing post:** 33

<div class="post-metadata">

**Author:** ![rhettinger](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rhettinger/32/1129_2.png) [@rhettinger](https://discuss.python.org/u/rhettinger)\
**Post date:** [April 24, 2023, 3:03pm UTC](https://discuss.python.org/t/pep-713-callable-modules/26127/33 "2023-04-24T15:03:49Z")

</div>

> [@jeanas](#):
>
> I honestly find calling a module object confusing from the intuitiveness and readability perspective.

Yes, aside from the occasional minor convenience, mostly this will just mess with people’s mental model of Python. Currently, there is a huge and easy to explain difference between `import pprint` and `from pprint import pprint`.

This PEP will put code reviewer in the awkward position of having to remember which modules have the call capability and remembering which version of Python that capability was added. For example, when is this code correct, `import pprint; pprint(dir())`.

Also, the premise that modules have only one principal capability is dubious. A module may start that way but can grow over time.

There is also the matter of spelling. We typically capitalize class names while lower casing function names. This is a problem for cases like the `graphlib` module that only features `TopologicalSorter`. We really don’t want instantiation with `ts = graphlib(*args)`. That would appear too much like a function call.

---

_[View the full topic](https://discuss.python.org/t/pep-713-callable-modules/26127)._