[prev in list] [next in list] [prev in thread] [next in thread]
List: python-ideas
Subject: [Python-ideas] Re: Reusing more builtins for type-hinting
From: Todd <toddrjen () gmail ! com>
Date: 2021-10-02 14:10:19
Message-ID: CAFpSVpJdyjSCAf6ZosP-_dgzmnSQywNvztKMu9jv45XVRMvShQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Is there a reason we can't use "Object" and make "Any" just an alias for
"Object"?
On Fri, Oct 1, 2021, 10:47 Christopher Barker <pythonchb@gmail.com> wrote:
>
>
> The fact that the built in "any" is not a type is not an implementation
> detail. any() and typing.Any are completely different things/concepts. They
> just happen to be spelled the same.
>
> I don't think it's a bad thing that objects that are specifically about
> Type Hinting can be found in the typing module.
>
> Overloading names in builtins to save an import is a really bad idea.
>
> -CHB
>
> On Fri, Oct 1, 2021 at 7:10 AM Ricky Teachey <ricky@teachey.org> wrote:
>
> > On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle <matthewgdv@gmail.com>
> > wrote:
> >
> > > I had no idea that type[Something] was already a thing, and this makes
> > > me so happy! :)
> > >
> > > It's true that `any` would have to converted to be either:
> > >
> > > 1) an object implementing __call__ and __getitem__
> > > 2) a type implementing __new__ and __class_getitem__
> > > 3) some special-cased type implemented in the interpreter that couldn't
> > > be recreated in python (like maybe implementing `any` as a special subclass
> > > of `builtin_function_or_method` that can be subscripted or allowing
> > > `builtin_function_or_method` to be optionally subscriptable)
> > > 4) some other option I'm not thinking of?
> > >
> > > The first two options would *technically* represent a
> > > backwards-incompatible change, but it's hard to imagine any **sane** code
> > > that would be affected. You'd have to be doing something like:
> > >
> > > ```
> > > import builtins
> > >
> > > builtin_function_or_method = type(max)
> > >
> > > for item in builtins.__dict__.values():
> > > if isinstance(item, builtin_function_or_method):
> > > ... # do something with all the builtin functions, which would
> > > no longer include `any`
> > > ```
> > >
> > > The third option would neatly sidestep this and be fully
> > > backwards-compatible, but I assume would represent a bigger change to the
> > > interpreter.
> > >
> > > As I don't have any knowledge of the interpreter's internals I can't
> > > really give a preference for an approach, but I think the first step would
> > > be agreeing that a subscriptable version of `any` for type-hinting is
> > > desirable.
> > >
> > > If this seems to be something that people want then I'm sure there are
> > > people far more qualified than me to discuss implementation details. If not
> > > then it's irrelevant anyway.
> > >
> > >
> > I'd expect to see something more like an EAFP construct;
> >
> > try:
> > maybe_all_maybe_mapping[key]
> > except KeyError:
> > # it's all()!
> >
> > I agree it would be weird. But not hard to imagine.
> >
> > ---
> > Ricky.
> >
> > "I've never met a Kentucky man who wasn't either thinking about going
> > home or actually going home." - Happy Chandler
> >
> >
> >
> > _______________________________________________
> > 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/GJZFK3VBIXFYAGYJSQVPFMRRGOK7B3NK/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> _______________________________________________
> 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/FJJ4G2ZHDTZS7ETVCXYXWRNQ3GAHK2BL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
[Attachment #5 (text/html)]
<div dir="auto"><div>Is there a reason we can't use "Object" and make \
"Any" just an alias for "Object"?<br><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 1, 2021, 10:47 \
Christopher Barker <<a \
href="mailto:pythonchb@gmail.com">pythonchb@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br></div><div \
dir="auto"><br></div><div dir="auto">The fact that the built in "any" is not a type \
is not an implementation detail. any() and typing.Any are completely different \
things/concepts. They just happen to be spelled the same. <br></div><div \
dir="auto"><br></div><div dir="auto">I don't think it's a bad thing that objects that \
are specifically about Type Hinting can be found in the typing module. </div><div \
dir="auto"><br></div><div dir="auto">Overloading names in builtins to save an \
import is a really bad idea. </div><div dir="auto"><br></div><div \
dir="auto">-CHB</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div \
dir="ltr" class="gmail_attr">On Fri, Oct 1, 2021 at 7:10 AM Ricky Teachey <<a \
href="mailto:ricky@teachey.org" target="_blank" \
rel="noreferrer">ricky@teachey.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div \
dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Fri, Oct 1, 2021 at \
9:49 AM Matt del Valle <<a href="mailto:matthewgdv@gmail.com" target="_blank" \
rel="noreferrer">matthewgdv@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div \
dir="ltr"><div>I had no idea that type[Something] was already a thing, and this makes \
me so happy! :)</div><div><br></div><div>It's true that `any` would have to \
converted to be either:</div><div><br></div><div>1) an object implementing __call__ \
and __getitem__</div><div>2) a type implementing __new__ and \
__class_getitem__<br></div><div>3) some special-cased type implemented in the \
interpreter that couldn't be recreated in python (like maybe implementing `any` \
as a special subclass of `builtin_function_or_method` that can be subscripted or \
allowing `builtin_function_or_method` to be optionally \
subscriptable)<br></div><div>4) some other option I'm not thinking \
of?</div><div><br></div><div>The first two options would *technically* represent a \
backwards-incompatible change, but it's hard to imagine any **sane** code that \
would be affected. You'd have to be doing something \
like:</div><div><br></div><div>```<br></div><div>import \
builtins<br></div><div><br></div><div>builtin_function_or_method = \
type(max)<br></div><div><br></div><div>for item in \
builtins.__dict__.values():</div><div> if isinstance(item, \
builtin_function_or_method):</div><div> ... # do something with all \
the builtin functions, which would no longer include \
`any`<br></div><div>```</div><div><br></div><div></div><div>The third option would \
neatly sidestep this and be fully backwards-compatible, but I assume would represent \
a bigger change to the interpreter.</div><div><br></div><div>As I don't have any \
knowledge of the interpreter's internals I can't really give a preference for \
an approach, but I think the first step would be agreeing that a subscriptable \
version of `any` for type-hinting is desirable.</div><div><br></div><div>If this \
seems to be something that people want then I'm sure there are people far more \
qualified than me to discuss implementation details. If not then it's irrelevant \
anyway.<br></div></div><br></blockquote><div> </div><div>I'd expect to see \
something more like an EAFP construct;<br><br>try:</div><div> \
maybe_all_maybe_mapping[key]</div><div>except KeyError:</div><div> # it's \
all()!</div><div><br></div><div>I agree it would be weird. But not hard to \
imagine.</div><div><div dir="ltr" data-smartmail="gmail_signature"><div \
dir="ltr"><div><br></div><div>---</div>Ricky.<br><br>"I've never met a \
Kentucky man who wasn't either thinking about going home or actually going \
home." - Happy Chandler</div></div></div><br></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div></div></div> \
_______________________________________________<br> Python-ideas mailing list -- <a \
href="mailto:python-ideas@python.org" target="_blank" \
rel="noreferrer">python-ideas@python.org</a><br> To unsubscribe send an email to <a \
href="mailto:python-ideas-leave@python.org" target="_blank" \
rel="noreferrer">python-ideas-leave@python.org</a><br> <a \
href="https://mail.python.org/mailman3/lists/python-ideas.python.org/" \
rel="noreferrer noreferrer" \
target="_blank">https://mail.python.org/mailman3/lists/python-ideas.python.org/</a><br>
Message archived at <a \
href="https://mail.python.org/archives/list/python-ideas@python.org/message/GJZFK3VBIXFYAGYJSQVPFMRRGOK7B3NK/" \
rel="noreferrer noreferrer" \
target="_blank">https://mail.python.org/archives/list/python-ideas@python.org/message/GJZFK3VBIXFYAGYJSQVPFMRRGOK7B3NK/</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer \
noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br> \
</blockquote></div></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div \
dir="ltr">Christopher Barker, PhD (Chris)<br><br> Python Language Consulting<br> - \
Teaching<br> - Scientific Software Development<br> - Desktop GUI and Web \
Development<br> - wxPython, numpy, scipy, Cython<br></div></div> \
_______________________________________________<br> Python-ideas mailing list -- <a \
href="mailto:python-ideas@python.org" target="_blank" \
rel="noreferrer">python-ideas@python.org</a><br> To unsubscribe send an email to <a \
href="mailto:python-ideas-leave@python.org" target="_blank" \
rel="noreferrer">python-ideas-leave@python.org</a><br> <a \
href="https://mail.python.org/mailman3/lists/python-ideas.python.org/" \
rel="noreferrer noreferrer" \
target="_blank">https://mail.python.org/mailman3/lists/python-ideas.python.org/</a><br>
Message archived at <a \
href="https://mail.python.org/archives/list/python-ideas@python.org/message/FJJ4G2ZHDTZS7ETVCXYXWRNQ3GAHK2BL/" \
rel="noreferrer noreferrer" \
target="_blank">https://mail.python.org/archives/list/python-ideas@python.org/message/FJJ4G2ZHDTZS7ETVCXYXWRNQ3GAHK2BL/</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer \
noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br> \
</blockquote></div></div></div>
_______________________________________________
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/YX5F2SOYTFQ54FDXSEUBU2MWFGOIJHDA/
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic