Re: [Python-ideas] Should iscoroutine and iscoroutinefunction be in builtins?

On Sun, Jul 2, 2017 at 8:18 PM, Alex Walters wrote: > Before async/await it made sense that iscoroutine and iscoroutinefunction > live in asyncio. But now that coroutines are a built in type, supported by > its own syntax, wouldn't it make sense to make those functions builtins? Technically "bui

Re: [Python-ideas] Should iscoroutine and iscoroutinefunction be in builtins?

On Sun, Jul 02, 2017 at 11:18:04PM -0400, Alex Walters wrote: > Before async/await it made sense that iscoroutine and iscoroutinefunction > live in asyncio. But now that coroutines are a built in type, supported by > its own syntax, wouldn't it make sense to make those functions builtins? Genera

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

On Mon, Jul 03, 2017 at 11:04:58AM +1200, Greg Ewing wrote: > 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 > gua

Re: [Python-ideas] Arguments to exceptions

On Sun, Jul 02, 2017 at 12:19:54PM -0700, Ken Kundert wrote: [...] > >>> try: > ... foo > ... except Exception as e: > ... print('str:', str(e)) > ... print('args:', e.args) > str: name 'foo' is not defined > args: ("name 'foo' is not defined",) > > Notice

[Python-ideas] Should iscoroutine and iscoroutinefunction be in builtins?

Before async/await it made sense that iscoroutine and iscoroutinefunction live in asyncio. But now that coroutines are a built in type, supported by its own syntax, wouldn't it make sense to make those functions builtins? ___ Python-ideas mailing list P

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 typ

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, w

[Python-ideas] Arguments to exceptions

All, Here is a proposal for enhancing the way BaseException handles arguments. -Ken Rationale = Currently, the base exception class takes all the unnamed arguments passed to an exception and saves them into args. In this way they are available to the exception handler. A commonl

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 > it. > That may hav

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 runtime, just as the -OO flag

Re: [Python-ideas] Bytecode JIT

On 2017-07-02 02:41 AM, Steven D'Aprano wrote: On Sat, Jul 01, 2017 at 07:52:55PM -0300, Soni L. wrote: On 2017-07-01 07:34 PM, Victor Stinner wrote: Let's say that you have a function "def mysum (x; y): return x+y", do you always want to use your new IADD instruction here? What if I call my

Re: [Python-ideas] Bytecode JIT

On Sun, Jul 2, 2017 at 10:13 PM, Steven D'Aprano wrote: >> But that's still a hard problem. Or at very least, it's decidedly >> non-trivial, and the costs are significant, so the net benefits aren't >> proven. > > In fairness, they are proven for other languages, and they certainly > worked for th

Re: [Python-ideas] Bytecode JIT

On Sun, Jul 02, 2017 at 03:52:34PM +1000, Chris Angelico wrote: > On Sun, Jul 2, 2017 at 3:41 PM, Steven D'Aprano wrote: > >> Let's say that you do. Given how short it is, it would just get inlined. > >> Your call of mysum ("a", "b") would indeed not use IADD, nor would it be > >> a call. It would

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 li

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

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 runtime, just as the -OO flag strips > > docstrings. That becomes 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 > want annotations, you d

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 type