Łukasz Langa <luk...@langa.pl> added the comment:

> Hm, 20% isn't so bad, but one of the arguments for NewType was that it 
> "disappears" at runtime -- which the current version does, but the 
> class-based version doesn't quite.

NewType was described originally in https://github.com/python/typing/issues/189 
and the resulting PEP text landed in 
https://github.com/python/typing/pull/226/files.

I find the 20% performance impact non-ideal but ultimately worth it because:
- it solves the issue described in this bug;
- it allows us to implement issubclass/isinstance in the future if we so choose;
- it also potentially allows us to chain NewType.

Since we can't fully rely on `from __future__ import annotations` to side-step 
the performance cost, we don't really have a different option than to change 
it. The alternative is to leave it as is which makes it a non-composable 
pseudo-type unlike the others.

Currently adoption of NewType is relatively low, in part due to the feature's 
obscurity and partially because of its limits. Slower instantiation performance 
will at worst keep the adoption low, but it can potentially bring more users to 
NewType since it becomes less hacky.

I'm +1 to converting to a class as done by the PR.


> Right now I don't have the cycles to think about this deeply. Maybe a few 
> weeks after I'm back from vacation (~August 8) I will have more time.

Sorry, I overeagerly already merged the change to `main`. Let's hold off with 
the 3.10 backport until you had time to think about it. If we decide against 
the change after all, reverting on `main` should have no negative impact since 
we're pre-alpha 1.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue44353>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to