[Python-ideas] CoC violation warning (was: Re: PEP 484 evolution)

[Brett Cannon]

I tried to be calm about asking the tone to be turned down on this topic,
but I feel like I wasn't listened to, so consider this your *official
warning, Rick*: *stop the bombastic, insulting tone or you will be banned*.
It is not considerate or respectful to call type hints an "abortion of
readability" and claim we are suffering from "an identity crisis" thanks to
this "philosophical perversion" brought on by this "type-hint nightmare".
Plenty of people on this list had a thorough, cordial discussion on this
topic long before you joined it and you do not have the right to come here
and suddenly start disparaging their hard work (not to mention those people
who aren't on this list who also participated in the discussion and
eventual implementation). If type hints upset you that much you are welcome
to not use Python anymore and "go running back into the loving arms of
Java" if you prefer.

I'm also asking everyone to consider this discussion of removing type hints
dead, so please be respectful of other people's time and don't reply to
this thread.

On Sat, 19 Mar 2016 at 13:15 Rick Johnson <rantingrickjohnson at gmail.com>
wrote:

> 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?
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160320/f3414619/attachment.html>