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
_______________________________________________
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/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