On Sun, Jun 16, 2019 at 7:41 PM Steven D'Aprano <st...@pearwood.info> wrote: > > On Sun, Jun 16, 2019 at 08:04:44AM -0700, Christopher Barker wrote: > > On Sun, Jun 16, 2019 at 6:08 AM Franklin? Lee > > <leewangzhong+pyt...@gmail.com> > > wrote: > > > > > The proposed feature is for expressing type relations, which only > > > matters when you care about types. The feature will only be useful > > > when you care about types. The syntax will only help/hurt readability > > > when the code cares about types. > > > > > > > And Python programmers rarely care about types -- that's why we use Python.d > > I'm pretty sure that Python programmers *frequently* care about types. I > know I do. How else do you avoid TypeErrors and AttributeErrors, if you > don't care what type of data you're using? > > What they might not be doing is *explicitly* type-checking using > isinstance or issubclass, but that doesn't mean they don't care about > types. Whether we duck-type, or LBYL with an explicit test, or EAPF with > a try...except block, or just rely on the caller never passing the wrong > thing to our functions, we still care about types.
I second on that, a lot of people who uses Python or Ruby, end up writing their own type system (which is a major reason why language like scala becomes more and more popular and its user base has a lot of former dynamic language users). This is especially true for library and framework developers, where you want to capture issues early, e.g. by forcing policies and make sure user defined class is deriving from a common base class and some magic happens behind the scene. _______________________________________________ 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/HDUXDNGPIJ27DFGKSSTEZUGNAHCJITE3/ Code of Conduct: http://python.org/psf/codeofconduct/
