Re: Static typing implementation for Python
Chris Angelico writes: > I'm fairly sure most arguments about "readable" or "unreadable" code > follow the same definitions. Does it ever. I never thought annotating names one added with one's initials or copy-pasting code instead of having a boolean expression in an if statement or keeping old code as comments improve readability. But that's what I was just told recently by someone. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing implementation for Python
Random832 writes: > Ben Finney writes: > > The opposite of string typing is weak typing. > > Well, I would say *string* typing [as used in, for example, sh and tcl] > is actually a form of weak typing. I infer a smile as you write that, but to clarify for others: I made a typo, and meant to contrast weak typing with strong typing. -- \“Like the creators of sitcoms or junk food or package tours, | `\ Java's designers were consciously designing a product for | _o__) people not as smart as them.” —Paul Graham | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing implementation for Python
On Mon, Oct 12, 2015 at 8:33 AM, Random832 wrote: > Ben Finney writes: >> The opposite of string typing is weak typing. > > Well, I would say *string* typing [as used in, for example, sh and tcl] > is actually a form of weak typing. But anyway, the other issue is that > strong typing is meaningless. In general it seems like weak typing means > "the existence of implicit operations (either type conversions or any > other operation between objects of different types) that I don't like". > > "Duck typing" of the sort that Python has, for example, could be and > sometimes is regarded as a form of weak typing. "Strong typing" is anything the current speaker likes. "Weak typing" is anything the current speaker dislikes. I'm fairly sure most arguments about "readable" or "unreadable" code follow the same definitions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing implementation for Python
Ben Finney writes: > The opposite of string typing is weak typing. Well, I would say *string* typing [as used in, for example, sh and tcl] is actually a form of weak typing. But anyway, the other issue is that strong typing is meaningless. In general it seems like weak typing means "the existence of implicit operations (either type conversions or any other operation between objects of different types) that I don't like". "Duck typing" of the sort that Python has, for example, could be and sometimes is regarded as a form of weak typing. -- https://mail.python.org/mailman/listinfo/python-list
Static typing implementation for Python (was: Strong typing implementation for Python)
John Michael Lafayette writes:
> I would like Python to have a strong typing feature that can co-exist
> with the current dynamic typing system.
You have incorrectly conflated two separate matters.
The opposite of string typing is weak typing. Python has strong typing:
its objects will only behave according to the type they're defined as,
and won't pretend to be what they're not.
The opposite of dynamic typing is static typing. Python has dynamic
typing: references are not at all restricted in what type of object they
reference.
> I would like Python to also be able to also do this:
>
> Animal a = Factory.make("dog")# okay. Dog is Animal.
> Dog d = Factory.make("dog") # okay. Dog is Dog.
> Cat c = Factory.make("cat") # Runtime error. Dog is not Cat.
By that example, you appear to want static typing: references are
restricted to a particular type and cannot refer to other types.
The two ends of that spectrum are pretty much incompatible: to gain
static typing, you must lose dynamic typing.
That does not strike me as an improvement for Python. There are plenty
of statically-typed languages; why would you want Python to lose its
dynamic typing?
> With a strong typing option that performs runtime type checking, the
> reader can be certain that the program is running the type they
> expect. Also, the IDE can be more helpful.
Type annotations https://www.python.org/dev/peps/pep-3107/> and
type hints https://www.python.org/dev/peps/pep-0484/> are both in
Python already.
They are entirely optional: code which does not use them can ignore them
completely. However, they appear to provide the benefits you describe,
without losing any of the power of dynamic typing.
--
\ “When cryptography is outlawed, bayl bhgynjf jvyy unir |
`\ cevinpl.” —Anonymous |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
