Re: [Python-Dev] Obtaining stack-frames from co-routine objects

2015-06-14 Thread Guido van Rossum
A good plan. I think this could be added to 3.5 still? It's a pretty minor
adjustment to the PEP 492 machinery, really.

On Sat, Jun 13, 2015 at 6:16 PM, Nick Coghlan  wrote:

>
> On 14 Jun 2015 10:01, "Ben Leslie"  wrote:
> >
> > If this seems like a good approach I'll try and work it in to a
> > suitable patch for contribution.
>
> I think it's a good approach, and worth opening an enhancement issue for.
>
> I expect any patch would need some adjustments after Yury has finished
> revising the async/await implementation to address some beta compatibility
> issues with functools.singledispatch and Tornado.
>
> Cheers,
> Nick.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Obtaining stack-frames from co-routine objects

2015-06-14 Thread Ben Leslie
Per Nick's advice I've created enhancement proposal 245340 with an
attached patch.

On 14 June 2015 at 19:16, Guido van Rossum  wrote:
> A good plan. I think this could be added to 3.5 still? It's a pretty minor
> adjustment to the PEP 492 machinery, really.
>
> On Sat, Jun 13, 2015 at 6:16 PM, Nick Coghlan  wrote:
>>
>>
>> On 14 Jun 2015 10:01, "Ben Leslie"  wrote:
>> >
>> > If this seems like a good approach I'll try and work it in to a
>> > suitable patch for contribution.
>>
>> I think it's a good approach, and worth opening an enhancement issue for.
>>
>> I expect any patch would need some adjustments after Yury has finished
>> revising the async/await implementation to address some beta compatibility
>> issues with functools.singledispatch and Tornado.
>>
>> Cheers,
>> Nick.
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Obtaining stack-frames from co-routine objects

2015-06-14 Thread Nick Coghlan
On 14 Jun 2015 19:17, "Guido van Rossum"  wrote:
>
> A good plan. I think this could be added to 3.5 still? It's a pretty
minor adjustment to the PEP 492 machinery, really.

Good point - as per Ben's original post, the lack of it makes it quite hard
to get a clear picture of the system state when using coroutines in the
current beta.

Cheers,
Nick.

>
> On Sat, Jun 13, 2015 at 6:16 PM, Nick Coghlan  wrote:
>>
>>
>> On 14 Jun 2015 10:01, "Ben Leslie"  wrote:
>> >
>> > If this seems like a good approach I'll try and work it in to a
>> > suitable patch for contribution.
>>
>> I think it's a good approach, and worth opening an enhancement issue for.
>>
>> I expect any patch would need some adjustments after Yury has finished
revising the async/await implementation to address some beta compatibility
issues with functools.singledispatch and Tornado.
>>
>> Cheers,
>> Nick.
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Obtaining stack-frames from co-routine objects

2015-06-14 Thread Mark Lawrence

On 14/06/2015 11:50, Ben Leslie wrote:

Per Nick's advice I've created enhancement proposal 245340 with an
attached patch.



http://bugs.python.org/issue24450 as opposed to 
http://bugs.python.org/issue24450#msg245340 :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython (merge 3.4 -> default): null merge with 3.4

2015-06-14 Thread Ned Deily
In article <[email protected]>,
 senthil.kumaran  wrote:
> https://hg.python.org/cpython/rev/9a0c5ffe7420
> changeset:   96605:9a0c5ffe7420
> parent:  96603:47a566d6ee2a
> parent:  96604:3ded282f9615
> user:Senthil Kumaran 
> date:Sun Jun 14 17:37:09 2015 -0700
> summary:
>   null merge with 3.4
> 
> Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple 
> documentation typos.
> 
> Related Issues:
> #issue21528
> #issue24453
> 
> files:

Senthil,

There is now an active 3.5 branch, so the correct current order of 
merging is:

3.4 -> 3.5
3.5 -> default

I've checked in a couple of null merges to try to fix things.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com