On Fri, Oct 8, 2021 at 4:27 PM Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Oct 9, 2021 at 10:02 AM Jeremiah Paige <ucod...@gmail.com> wrote: > > > > On Fri, Oct 8, 2021 at 2:30 PM Chris Angelico <ros...@gmail.com> wrote: > >> > >> On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige <ucod...@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 > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/QADKWE5MIVB43CZTRULRNLSFTRF4FFIM/ > 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-le...@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/7EKOQIYWGI3ARZH4QL77SSUWTOULGQN7/ Code of Conduct: http://python.org/psf/codeofconduct/
