I suspect there won’t be enough support for this proposal to ever make it
happen, but at the very least could you think of a different token? The
three left arrows just look too weird (esp. in the REPL examples, where
they strongly seem to suggest a false symmetry with the ‘>>>’ prompt. How
did you decide to use this symbol?
On Fri, Oct 15, 2021 at 14:25 Jeremiah Paige
On Fri, Oct 8, 2021 at 4:27 PM Chris Angelico
wrote: On Sat, Oct 9, 2021 at 10:02 AM Jeremiah Paige
wrote: On Fri, Oct 8, 2021 at 2:30 PM Chris Angelico
wrote: On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige
wrote:
Bellow are some examples of where I believe the reflection token would be used if adopted.
>> Point = namedtuple(<<<, 'x, y, z') >> 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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QADKWE... Code of Conduct: http://python.org/psf/codeofconduct/
Here is a pseudo-program showing where I would like to use this token in my own code if it existed. I think besides the cases where one is forced to always repeat the variable name as a string (namedtuple, NewType) this is an easy way to express clear intent to link the variable name to either its value or original source.
REGION = os.getenv(<<<) db_url = config[REGION][<<<]
name = arguments.get(<<<)
con = connect(db_url) knights = <<< horse = <<< con.execute(f"SELECT * FROM {knights} WHERE {horse}=?", (name,))
Using the new token like this will remove bugs where the variable name was spelled correctly, but the string doing the lookup has a typo. Admittedly this is a small set of bugs, but I have run into them before. Where I see this being a bigger advantage is purposefully linking variables names within python to names outside, making it easier to refactor and easier to trace usage across an entire service and across different environments.
For the other use, in factory functions, I believe we have just come to accept that it is okay to have to repeat ourselves to dynamically generate certain objects in a dynamic language. The fact is that variable names are relevant in python and can be a useful piece of information at runtime as well as compile time or for static analysis. This is why some objects have a __name__: it is useful information despite the fact it may not always be accurate.
def foo(): pass
bar = foo del foo bar.__name__ 'foo'
It may not be incredibly common but it is a power that the compiler has that is not really available to the programmer. And not every place where variable name access can be used would benefit from being implemented with the large class object and the complex implementation of a metaclass.
Regards, ~ Jeremiah _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7EKOQI... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)