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.
Besides these two and the two more in the test file, the standard
library has type, new_class, import_module, TypedDict, ParamSpec,
and probably more, less used, factories I have missed.
> >>> class Colors(Enum):
> ... Black = <<<
> ... GRAY = <<<
> ... WHITE = <<<
> ...
> >>> Colors.GRAY.value
> 'GRAY'
Can do this just as easily using Enum.auto().
That's fair, but this works for constants in dataclasses, attrs, generally
any class or namespace.
> >>> 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.
Perhaps the concatenation, showing it is just a string, was a poor
example. In my own code I often make strings that are reused, such as
for dict key access, variables of the same spelling. It looks like cpython
also does this at least a few hundred times.
> >>> 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.py.
>
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.
The syntax is not only helpful to dictionary unpacking, but any retrieval by
string and so is general to e.g. match.group, list.index, Message.get.
Regards
~ Jeremiah