[Python-ideas] PEP 484 (Type Hints) -- second draft

[Cameron Simpson]

On 24Mar2015 10:56, Chris Angelico <rosuav at gmail.com> wrote:
>On Tue, Mar 24, 2015 at 8:05 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 23 March 2015 at 19:55, Guido van Rossum <guido at python.org> wrote:
>>>> * +1 for the argument order cast(x, T). This is consistent with (x: T)
>>>> elsewhere.
>>>
>>> I disagree on this. It goes against the argument order of casts in other
>>> languages, e.g. C, C++, Java, and even in Python -- you write int(x), not
>>> x(int).

Well, in C you write (T)x, but I would expect that to be a syntactic 
requirement. Had it been framed as a function call I would not find cast(x, T) 
surprising at all.

>> However, in SQL, which is the only language I know of with an with an
>> explicitly named cast function [...] the syntax is
>> CAST(foo AS type). [...]
>> stronger, depending on your background) for cast(x, T).
>
>I would *hope* that some stronger argument is used than "SQL puts it
>this way".

Shrug. It is a consistency argument. And language like SQL and (gasp) COBOL 
strive in a sense for English prose friendliness.

>In this case, the isinstance() parallel is a better argument than the
>SQL cast, but it's a small point and I could easily be tipped back to
>preferring cast(T, x).

I would not. Leaving aside object method calls (fp.write(blah)), usually the 
thing acted upon or through is the first function agrument:

  write(fd, data, size)
  find(string, substring)
  heapsort(mylist)
  frob(widget, frobbificationness)

I also like the instance() argument.

For the record, I am +1 for cast(x, T).

Cheers,
Cameron Simpson <cs at zip.com.au>

Artificial intelligence won't make a micrometer out of a monkeywrench.
        - Rick Gordon <rickg at crl.com>