On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige <ucodery@gmail.com> wrote:
Bellow are some examples of where I believe the reflection token would be used if adopted.
Point = namedtuple(<<<, 'x, y, z') Point <class '__main__.Point'>
UUIDType = NewType(<<<, str) UUIDType __main__.UUIDType
Not very commonly needed. The class keyword handles this just fine; namedtuple does require that repetition, but I don't know of any other cases where people construct types like this.
class Colors(Enum): ... Black = <<< ... GRAY = <<< ... WHITE = <<< ... Colors.GRAY.value 'GRAY'
Can do this just as easily using Enum.auto().
HOME = '$' + <<< HOME '$HOME'
Wow, this is so incredibly useful. I'm sure I would use this construct *at least* once per decade if it existed.
if error := response.get(<<<): ... if errorcode := error.get(<<<): ... print(f"Can't continue, got {errorcode=}") ... Can't continue, got errorcode=13
Ugh. I'm sure there would be better ways to advocate unpacking but this really isn't selling it.
To get a feel for using this new token I have created a fork of the 3.11 alpha that implements a *very* incomplete version of this new grammar, just enough to actually produce all of the examples above. It also passes a small new test suite with further examples https://github.com/ucodery/cpython/blob/reflection/Lib/test/test_reflection.....
General summary based on all of the examples in that file: Use the class statement more. There is absolutely no reason, for instance, to use make_dataclass in this way - just use the class statement instead. There *may* be some value in the use of TypeVar like this (not sure though), in which case there'd be two mildly tempting use-cases, neither of which is hugely common (TypeVar and namedtuple). For the rest, a big ol' YAGNI on a syntax that badly impairs readability. And while I would somewhat like to see a dictionary unpacking syntax, this really isn't selling the concept well. ChrisA