Re: [Python-ideas] Runtime types vs static types

On Sun, Jul 2, 2017 at 2:16 PM, Steven D'Aprano wrote: > On Sat, Jun 24, 2017 at 10:42:19PM +0300, Koos Zevenhoven wrote: > > [...] > > Clearly, there needs to be some sort of distinction between runtime > > classes/types and static types, because static types can be more

Re: [Python-ideas] Runtime types vs static types

Steven D'Aprano wrote: I think that we should assume that def func(x:Spam()): ... will always look up and call Spam when the function is defined. Personally I think we should be moving towards not even guaranteeing that. Then we would have a chance of some day ending up with a static

Re: [Python-ideas] Runtime types vs static types

Steven D'Aprano wrote: isinstance([], List[int]) isinstance([], List[str]) How can a single value be an instance of two mutually incompatible types? I don't think there's any contradiction there, because the compatibility rules are different for static and runtime types. Statically,

Re: [Python-ideas] Runtime types vs static types

On Sun, Jul 2, 2017 at 4:54 AM, Steven D'Aprano wrote: > I think that the current status is that the MyPy folks, including Guido, > consider that it *is* reasonable to ask these questions for the purpose > of introspection, but issubclass and isinstance are not the way to do

Re: [Python-ideas] Runtime types vs static types

On 7/2/2017 7:57 AM, Steven D'Aprano wrote: On Sun, Jul 02, 2017 at 09:38:11PM +1000, Chris Angelico wrote: On Sun, Jul 2, 2017 at 9:16 PM, Steven D'Aprano wrote: If we want to support that optimization, we could add an optimization flag that strips annotations at

Re: [Python-ideas] Runtime types vs static types

@ Koos Zevenhoven > and there should at least *exist* a well-defined answer to whether an object is in 'instance' of a given type. (Not sure if 'instance' should be world used here) Let me illustrate why being an "instance" (or any other word) does not apply well to runtime objects. Consider a

Re: [Python-ideas] Runtime types vs static types

On Sun, Jun 25, 2017 at 09:13:44AM -0700, Lucas Wiman wrote: > > > > For some background on the removal of __instancecheck__, check the linked > > issues here: > > > > Thanks for the reference (the most relevant discussion starts here >

Re: [Python-ideas] Runtime types vs static types

On Sun, Jul 2, 2017 at 9:16 PM, Steven D'Aprano wrote: > If we want to support that optimization, we could add an optimization > flag that strips annotations at runtime, just as the -OO flag strips > docstrings. That becomes a matter of *consenting adults* -- if you don't >

Re: [Python-ideas] Runtime types vs static types

On Sat, Jun 24, 2017 at 10:42:19PM +0300, Koos Zevenhoven wrote: [...] > Clearly, there needs to be some sort of distinction between runtime > classes/types and static types, because static types can be more precise > than Python's dynamic runtime semantics. I think that's backwards: runtime

Re: [Python-ideas] Runtime types vs static types

On Thu, Jun 29, 2017 at 12:40 PM, Ivan Levkivskyi wrote: > Sorry, I was not able to completely digest the OP, but I think there are > some points I need to clarify. > > 1. Distinction between runtime classes and static types is quite sane and > a simple idea. > A runtime

Re: [Python-ideas] Runtime types vs static types

Sorry, I was not able to completely digest the OP, but I think there are some points I need to clarify. 1. Distinction between runtime classes and static types is quite sane and a simple idea. A runtime class is something associated with an actual object, while static type is something associated

Re: [Python-ideas] Runtime types vs static types

After rereading Koos' OP, I can now see that he was referring to a different kind of runtime type checking than I am interested in. There was a distinction I was unaware the core typing devs make between "typing-style types" and "classes" that I'll discuss further in the typing repo itself.

Re: [Python-ideas] Runtime types vs static types

On Sun, Jun 25, 2017 at 8:47 PM, Lucas Wiman wrote: > > ​Yes, but then `isinstance(tuple(range(100)), Tuple[int, ...])` > would be a difficult case. > > Yes, many methods on million-element tuples are slow. :-) > > Python usually chooses the more intuitive behavior

Re: [Python-ideas] Runtime types vs static types

> ​Yes, but then `isinstance(tuple(range(100)), Tuple[int, ...])` would be a difficult case. Yes, many methods on million-element tuples are slow. :-) Python usually chooses the more intuitive behavior over the faster behavior when there is a choice. IIUC, the objections don't have anything

Re: [Python-ideas] Runtime types vs static types

On Sun, Jun 25, 2017 at 7:13 PM, Lucas Wiman wrote: [...] > >>> from typing import * > >>> isinstance(0, Union[int, float]) > Traceback (most recent call last): > File "", line 1, in > File "/Users/lucaswiman/.pyenv/versions/3.6/lib/python3.6/typing.py", > line 767,

Re: [Python-ideas] Runtime types vs static types

> > For some background on the removal of __instancecheck__, check the linked > issues here: > Thanks for the reference (the most relevant discussion starts here ). That said, I think I totally disagree with the underlying

Re: [Python-ideas] Runtime types vs static types

For some background on the removal of __instancecheck__, check the linked issues here: https://github.com/python/typing/issues/135 -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone elsehttp://refi64.com On Jun 25, 2017 at 8:11 AM, > wrote: On Sat, Jun 24,

Re: [Python-ideas] Runtime types vs static types

On Sat, Jun 24, 2017 at 11:30 PM, Lucas Wiman wrote: > ​ > On Sat, Jun 24, 2017 at 12:42 PM, Koos Zevenhoven > wrote: > >> There has been some discussion here and there concerning the differences >> between runtime types and static types (mypy etc.).

[Python-ideas] Runtime types vs static types

There has been some discussion here and there concerning the differences between runtime types and static types (mypy etc.). What I write below is not really an idea or proposal---just a perspective, or a topic that people may want to discuss. Since the discussion on this is currently very fuzzy