[Python-ideas] PEP 484 evolution
Rick Johnson
rantingrickjohnson at gmail.com
Sat Mar 19 16:14:30 EDT 2016
On Sat, Mar 19, 2016 at 11:46 AM, Steven D'Aprano <steve at pearwood.info>
wrote:
> Take a deep breath and calm down. The type-hints are
> completely optional and nobody will be forced to use them.
I don't think it's fair for you to tell me to: "calm down
because this won't effect you". What evidence are you basing
that theory on? Type-hits will effect everyone.
Telling me to calm down is like: blowing up and damn, and
then telling the peasants to "clam down" because their
houses, and more troubling, their entire village was
destroyed as a result of actions that were "beyond their
control".
You, and a few others supporters, keep claiming that "type-
hints" are optional -- but while they may be optional to
*write*, they are *not* optional to *read*.
Furthermore, once source code is written that includes this
"interleaved syntax", the readability of the code will become
*permanently* damaged.
Observe the following:
# SIMPLE EXAMPLE WITHOUT TYPE HINTS:
def greeting(name):
return 'Hello, {}'.format(name)
# SIMPLE EXAMPLE WITH TYPE HINTS:
def greeting(name: str) -> str:
return 'Hello, {}'.format(name)
I couldn't just ignore the ": str" and the "-> str" even if
i wanted to, no more than i could ignore braces -- if python
gave us the option of defining blocks with braces. No, it's
there *forever*, mucking up the readability of the code. And
if that example seems too simplistic, then feast your eyes
on this "abortion of readability":
def greeting(names: Union[List[str], Dict[int, List[str]]]) -> Union[
List[str], Dict[int, List[str]]]:
fmt = 'Hello, {}'
if isinstance(names, dict):
return [(k, fmt.format(', '.join(v))) for k, v in
names.items()]
else:
return fmt.format(', '.join(names))
When faced with code like that, my first reaction is to go
running back into the loving arms of Java -- why would i use
Python? When Java offers *REAL* static typing; is compiled;
runs *EVERYWHERE*; executes far more quickly; and is not
suffering from an identity crisis.
============================================================
BUT THERE IS STILL HOPE...
============================================================
I assure you, we can introduce a "type-hint-spec" that won't
destroy the readability of Python source code -- by moving
the spec *OUTSIDE* of sigs...
Consider this:
def greeting(name):
# typehint: greeting(name:str) -> str
return 'Hello, {}'.format(name)
...or even this:
@typehint: greeting(name:str) -> str
def greeting(name):
return 'Hello, {}'.format(name)
...or by using stub files (but i understand why people hate
them, because of the "syncing issues" involved.)
...any of which, are a more Pythonic way to evolve.
and for sequence members, or other "member types", creating
new objects that enforce "explicit typing", along the lines
of array.array(type), is far more pythonic that introducing
*line noise* to force *all* objects to submit to this type-
hint nightmare.
>>> import array
>>> a1 = array.array
>>> a1 = array.array('i')
>>> a1.append(10)
>>> a1.append('10')
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
a1.append('10')
TypeError: an integer is required
You don't need type-hints where type can be *enforced*.
============================================================
WHAT DO WE CONSIDER IMPORTANT?
============================================================
*READABILITY* is the most cited reason for choosing Python,
followed closely behind by: rapid development and the
freedom of dynamic typing -- take away any of those, and
what's the point anymore? What's next, braces? How deep does
this "philosophical perversion" go? I can sum up this
"supposed feature" in one sentence...
type-hints (as implemented) shackles a programmer with
*ALL* of the syntactical onerous that any statically typed
language would demand, except, without offering any benefits
of *REAL* type-checking -- rr
Should a "feature", that is marketed as a "hint", shackle the
programmer with the same onerous that the *REAL* feature
would?
Consider the following observation of type-hints:
You have to write the hint *YOURSELF*, then, you have to
process the hint *YOURSELF* -- python does nothing but
ignore your "type-hint syntax".
So it's like: "Hey Python, i'll pay you two dollars if
you'll allow me to write this nasty type-hint syntax"...
So, python takes the two dollars, silently ignores the
nasty syntax, and then charges every reader a "readability
fee"...
SOMETHING IS SOOOOO WRONG HERE!
Contrary to popular belief, "type-hints" is not "feature",
no, it's a *FUNDAMENTAL TRANSFORMATION* of Python into a
completely different language! One that makes the same old
mistakes that every other language has made.
"Welcome to mediocrity, leave your expectations at the door"
If you think the people who love Python, because of it's
readability, are going to take this "type-hints absurdity"
lying down, well, then, you and "your supporters" are in for
a rude awakening! Whether intentional or not, type-hints
will effect *EVERY* Python programmer at some point in the
future -- even those that wish to avoid it.
And since Python has already suffered a terrible blow from
the release of Python3000, this "type-hints feature", if
implemented "as is", looks to be the final "nail in it's
coffin".
But we can prevent this if we do something *NOW*.
I implore each and every member to ask themselves the
following questions:
(1) What is the "essence of Python", that makes it such an
attractive language to use?
(2) If you had to compose a short list of the best
attributes of Python -- would type-hints be on that list?
If so, explain...
(3) How do you justify the irreversible damage to Python's
readability, that will be caused by this current
implementation of type-hints -- surely you're not taking the
position that: "no damage will be caused".
(4) What is *SO* important about type-hints that it over-
rides our fundamental philosophy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160319/d860a2c6/attachment-0001.html>
More information about the Python-ideas
mailing list