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 <ucod...@gmail.com> wrote: > > 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/ > -- --Guido (mobile)
_______________________________________________ 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/FGP2AAAFNGSKHTAYVNQEXWW6PO2E6VUE/ Code of Conduct: http://python.org/psf/codeofconduct/
