On Sat, Oct 9, 2021 at 6:24 AM Jeremiah Paige <[email protected]> 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.
> >>> class Colors(Enum):
> ... Black = <<<
> ... GRAY = <<<
> ... WHITE = <<<
> ...
> >>> Colors.GRAY.value
> 'GRAY'
Can do this just as easily using Enum.auto().
> >>> 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.
> >>> 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.
ChrisA
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/A3RTZXRCOPDPEROXZYXOQKQZTSPW3QYU/
Code of Conduct: http://python.org/psf/codeofconduct/
