On Fri, Oct 8, 2021 at 2:30 PM Chris Angelico <rosuav@gmail.com> wrote:
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.... .
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