On 18 May 2016 at 23:20, Daniel Holth wrote:
> I would like to take another stab at adding a threadlocal "str(bytes) raises
> an exception" to the Python interpreter, but I had a very hard time
> understanding both how to add a threadlocal value to either the interpreter
> state or the threadlocal
On 19 May 2016 at 05:04, Ethan Furman wrote:
> On 05/18/2016 11:52 AM, Neil Schemenauer wrote:
>> The whole finalize/shutdown logic of the CPython interpreter could
>> badly use some improvement. Currently it is a set of ugly hacks
>> piled on top of each other. Now that we have PEP 3121,
>>
>>
FYI, a few people gave useful feedback on my draft text, and I've now
pushed it to PEP 484. All new text is one section:
https://www.python.org/dev/peps/pep-0484/#the-type-of-class-objects
Next I'm going to implement it. Subscribe to this issue if you want to
follow along:
https://github.com/pytho
On 2016-05-18 15:20, Daniel Holth wrote:
> I would like to take another stab at adding a threadlocal "str(bytes)
> raises an exception" to the Python interpreter, but I had a very hard
> time understanding both how to add a threadlocal value to either the
> interpreter state or the threadlocal dict
No problem, I did not think you were attacking me or find your
response rude.
On Wed, May 18, 2016, at 01:06 PM, Cesare Di Mauro wrote:
> If you feel like I've attacked you, I apologize: it wasn't my
> intention. Please, don't get it personal: I only reported my honest
> opinion, albeit after a
On 05/18/2016 11:52 AM, Neil Schemenauer wrote:
Benjamin Peterson wrote:
Adding PyGC_CollectIfEnabled() and calling it in Py_Finalize is probably
fine. I don't think the contract of PyGC_Collect itself (or gc.collect()
for that matter) should be changed. You might want to disable GC but
invoke
Benjamin Peterson wrote:
> Adding PyGC_CollectIfEnabled() and calling it in Py_Finalize is probably
> fine. I don't think the contract of PyGC_Collect itself (or gc.collect()
> for that matter) should be changed. You might want to disable GC but
> invoke it yourself.
Yes, that sounds okay to me.
If you feel like I've attacked you, I apologize: it wasn't my intention.
Please, don't get it personal: I only reported my honest opinion, albeit
after a re-read it looks too rude, and I'm sorry for that.
Regarding the post-bytecode optimization issues, they are mainly
represented by the constant
Your criticisms may very well be true. IIRC though, I wrote that pass
because what was available was not general enough. The stackdepth_walk
function made assumptions that, while true of code generated by the
current cpython frontend, were not universally true. If a goal is to
move this calculation
2016-05-17 8:25 GMT+02:00 :
> In the project https://github.com/zachariahreed/byteasm I mentioned on
> the list earlier this month, I have a pass that to computes stack usage
> for a given sequence of bytecodes. It seems to be a fair bit more
> agressive than cpython. Maybe it's more generally use
I would like to take another stab at adding a threadlocal "str(bytes)
raises an exception" to the Python interpreter, but I had a very hard time
understanding both how to add a threadlocal value to either the interpreter
state or the threadlocal dict that is part of that state, and then how to
acce
11 matches
Mail list logo
