On Sat, Oct 9, 2021 at 10:02 AM Jeremiah Paige <ucodery@gmail.com> wrote:
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.
But most of those don't need to be used with constants. You don't use the type constructor when you could just use a class statement. I'm not sure about the others since I have literally never used them in production; which is an indication of how much they need special syntax to support them (namely: approximately zero).
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.
Can you provide better examples then? When you offer a new piece of syntax, saying "well, it could be useful for other things" isn't nearly as convincing as actual examples that will make people's lives better.
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.
Again, need better examples if it's to be of value. Preferably, show places where it's not just a matter of saving keystrokes (which are cheap) - show places where it reduces errors.
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.
Match groups (assuming they're named - personally, I more often use positional groups) and Message.get are definitely a plausible use-case for something, but this syntax isn't really selling it. I've no idea what your use-cases for list.index are. A generic unpacking syntax might be plausible, but it would need to handle multiple unpackings in a single operation, and it'd achieve something like: spam, ham, eggs, sausages = foo["spam"], foo["ham"], foo["eggs"], foo["sausages"] Writing that in a way that doesn't involve repeating the keys OR the thing being unpacked *would* be tempting, but the syntax you're proposing can't handle that. If your use-cases are like this, I would be much more inclined to recommend class syntax, maybe with a suitable decorator. It's a great way to create a namespace. You can do all kinds of namespace-like things by starting with a declarative structure and then giving that to whatever function you like. ChrisA