On 18/06/2019 11:06, Yanghao Hua wrote:
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
Really? I can honestly say I have never felt the need to invent a type
system for Python. The one occasion I have made use of type annotations
even caused me more trouble than it was worth (it caught one error that
would have come out in testing after I spent hours working out how to
break the circular dependencies that arose from trying to formalise
duck-typing).
(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).
The impression that I'm getting from colleagues is that Scala is busily
shooting itself in the foot at the moment, so I'm wary of taking lessons
from it. Disclaimer: none of us are habitual Scala programmers, so take
our collective opinions with a small mountain of salt.
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 isn't a language that does forcing easily or well. Please
correct me if I'm wrong, but I've always thought that was to a large
extent deliberate. It may be unpopular in general computing right now,
but we've always dealt with such potential problems with documentation.
(I may be slightly bitter at the moment. I had to spend far too long
yesterday reading the code of a C library because the limited
documentation failed to mention quite a lot of things, and the examples
of how to use it managed to be both trivial and misleading.)
--
Rhodri James *-* Kynesim Ltd
_______________________________________________
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/A7IRL26KBRATDSIQATDHWPJ53U7L3IY7/
Code of Conduct: http://python.org/psf/codeofconduct/
