Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Condition can't be inferred, unable to merge overloads #112

Closed
daxpryce opened this issue Mar 11, 2022 · 5 comments
Closed

Condition can't be inferred, unable to merge overloads #112

daxpryce opened this issue Mar 11, 2022 · 5 comments

Comments

@daxpryce
Copy link

daxpryce commented Mar 11, 2022 •
edited

So, with 10.3 releasing, our nightly downstream dependency check build failed telling us:

mypy ./graspologic
/Users/runner/hostedtoolcache/Python/3.7.12/x64/lib/python3.7/site-packages/beartype/_decor/main.py:294: error: Condition can't be inferred, unable to merge overloads
Found 1 error in 1 file (checked 79 source files)

Mypy coming in with the best error messages that tell me nothing actionable there, but it at least seems like it's sad at something in the new beartype? Any ideas @leycec? It's entirely too Friday to have to deal with this shit, so I'm sorry about that!

https://github.com/microsoft/graspologic/runs/5513695671?check_suite_focus=true#step:6:1 - for if you would like to inspect any other of the entirely overcomplicated CICD build process that may have some impact on this
@twoertwein twoertwein mentioned this issue Mar 11, 2022
Closed
@twoertwein
Copy link

Might be a mypy 0.940 issue. When I downgrade mypy to 0.931 I do not get this error.

@twoertwein twoertwein mentioned this issue Mar 11, 2022
Closed
@twoertwein
Copy link

I think this issue can be closed, see python/mypy#12335 (comment).

@leycec It might be worth to have a quick release with the workaround suggested by @cdce8p (see the linked comment).

@leycec
Copy link
Member

leycec commented Mar 11, 2022 •
edited

ohnoes. The inglorious 0.10.x dev cycle continues with an unexpected free bonus epilogue chapter. Thanks so much for the rapid response time, @daxpryce and @twoertwein. The direct link to @cdce8p's proposed zero-day hot fix was especially helpful, @twoertwein!

beartype 0.10.4 be like:

@leycec
Copy link
Member

leycec commented Mar 12, 2022

Sadly, mypy 0.940 condemns us. @cdce8p's solution does resolve the exact issue in question – but then causes mypy 0.940 to explosively emit two new errors and one warning concerning the same if conditional:

beartype/_decor/main.py:71: error: The implementation for an overloaded function must come last  [misc]
beartype/_decor/main.py:329: error: Overloaded function implementation cannot satisfy signature 2 due to inconsistencies in how they use type variables  [misc]
beartype/_decor/main.py:329: note: Error code "misc" not covered by "type: ignore" comment
Found 2 errors in 1 file (checked 166 source files)

What we're saying is:

This gonna take some time.

Until we get mypy 0.940 fully sorted, please temporarily abase your codebases by dropping down to mypy 0.931. It's an ugly world we inhabit, folks. This must be further proof we're on the Bad historical timeline. 😨

leycec added a commit that referenced this issue Mar 12, 2022
@leycec
mypy 0.940 + beartype.vale no-noop.
ccac042 
This commit improves compatibility with recently released mypy 0.940,
resolving issues #111 and #112 dual-reported concurrently by
cutting-edge Microsoft luminary @daxpryce and German typing bad-ass
@twoertwein. Specifically, this commit fundamentally refactors (and in
so doing mildly optimizes) our private `beartype._decor.main` submodule
to leverage conditional overloads under the astute tutelage
of mypy maestro @cdce8p; the `@beartype.beartype` decorator itself now
resides in a new private
`beartype._decor.cache.decor.cachedecor` submodule, because obfuscation
is the key to all successful open-source efforts. Relatedly, this
commit also partially resolves issue #94 (kindly requested by typing
monster @matanster) by optimizing the definition of the
`@beartype.beartype` decorator when that decorator reduces to a noop
(e.g., due to `python3 -O` optimization). Unrelatedly, this commit also
resolves a critical defect in our new functional API (i.e., the pair of
`beartype.abby.is_bearable()` and `beartype.abby.die_if_unbearable()`
functions), which previously reduced to a noop when the
`@beartype.beartype` decorator reduced to a noop; extricating the
`@beartype.beartype` decorator into the
`beartype._decor.cache.decor.cachedecor` submodule enables our
functional API to unconditionally depend upon that decorator regardless
of what we present to external users. Thanks so much for the rapid
response time, everyone! `beartype 0.10.4` will be en-route to a
cheeseshop near you shortly. (*Incorrigibly durable didgeridoo!*)
@leycec
Copy link
Member

leycec commented Mar 12, 2022

Resolved by ccac042. It turns out that if you don't sleep, you can solve problems. Tests pass. Therefore, we pass out. 😴

Oh – and we're dropping the beartype 0.10.4 bomb bundle of joy "soon." Soon probably means Sunday or Monday evening. (On Saturdays, I pretend none of this is happening.)

@leycec leycec closed this as completed Mar 12, 2022
leycec added a commit that referenced this issue Mar 15, 2022
@leycec
**Beartype 0.10.4** released.
c98cf6e 
This patch release adumbrates with breathless support for **mypy ≥
0.940,** the static type checker formerly known as "The Static Type
Checker Whose Name Shall not Be Spoken."

This patch release resolves **5 issues** and merges **0 pull requests.**
Noteworthy changes include:

## Compatibility Improved

* **mypy ≥ 0.940.** The `beartype` codebase now sports improved
  compatibility with recently released mypy 0.94x series, which
  previously outted the `@beartype` decorator with a "Condition can't be
  inferred, unable to merge overloads [misc]" fatal error at static
  type-checking time. Specifically, this commit fundamentally refactors
  (and in so doing mildly optimizes) our private `beartype._decor.main`
  submodule to leverage conditional overloads under the astute tutelage
  of mypy maestro @cdce8p; the `@beartype.beartype` decorator itself now
  resides in a new private `beartype._decor.cache.cachedecor` submodule,
  because obfuscation is the key to all successful open-source efforts.
  Doing so resolves issues #111 and #112 dual-reported concurrently by
  cutting-edge Microsoft luminary @daxpryce and German typing bad-ass
  @twoertwein.

## Features Optimized

* **Importation time.** The first external importation from the
  `beartype` codebase is now significantly faster when the definition of
  the `@beartype.beartype` decorator reduces to a noop (e.g., due to
  `python3 -O` optimization), partially resolves issue #94 kindly
  requested by the well-tanned and -toned typing star @matanster.

## Issues Resolved

* **`beartype.abby` under `python3 -O`.** This release resolves an
  unreported critical defect in our new functional API (i.e., the pair
  of `beartype.abby.is_bearable()` and
  `beartype.abby.die_if_unbearable()` functions), which previously
  reduced to a noop when the `@beartype.beartype` decorator reduced to a
  noop (e.g., due to `python3 -O` optimization). By extricating the
  `@beartype.beartype` decorator into the
  `beartype._decor.cache.cachedecor` submodule (as described above),
  our functional API now directly defers to that decorator regardless of
  what the `beartype` package externally presents to third-party code.

(*Ironwrought irony untaught!*)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@leycec @daxpryce @twoertwein