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.
> > >>> 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.
> > >>> 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.
>
> > >>> if error := response.get(<<<):
> > ... if errorcode := error.get(<<<):
> > ... print(f"Can't continue, got {errorcode=}")
> > ...
> > Can't continue, got errorcode=13
>
> Ugh. I'm sure there would be better ways to advocate unpacking but
> this really isn't selling it.
>
> > To get a feel for using this new token I have created a fork of the 3.11
> alpha that implements a *very* incomplete version of this new grammar, just
> enough to actually produce all of the examples above. It also passes a
> small new test suite with further examples
> https://github.com/ucodery/cpython/blob/reflection/Lib/test/test_reflection.py
> .
> >
>
> General summary based on all of the examples in that file: Use the
> class statement more. There is absolutely no reason, for instance, to
> use make_dataclass in this way - just use the class statement instead.
> There *may* be some value in the use of TypeVar like this (not sure
> though), in which case there'd be two mildly tempting use-cases,
> neither of which is hugely common (TypeVar and namedtuple). For the
> rest, a big ol' YAGNI on a syntax that badly impairs readability.
>
> And while I would somewhat like to see a dictionary unpacking syntax,
> this really isn't selling the concept well.
>
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.
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/WOCRCFG4465CFVCQ5DDYBZ34IQO553HL/
Code of Conduct: http://python.org/psf/codeofconduct/
