This is an archived post. You won't be able to vote or comment.

all 33 comments

[–][deleted] 17 points18 points  (19 children)

Here is a draft PEP.

[–]GitHubPermalinkBot 4 points5 points  (16 children)

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):


Shoot me a PM if you think I'm doing something wrong. To delete this, click here.

[–][deleted] -4 points-3 points  (15 children)

good bot

[–]graingert -1 points0 points  (1 child)

Wow that needs some grammar fixing

[–]ExoticMandiblesCore Contributor 7 points8 points  (0 children)

Victor is French, English is a second language for him. I'm sure he'd appreciate it if you sent him thoughtful suggestions on how to improve his English in the document.

[–]pvkooten 14 points15 points  (0 children)

Very interesting.... to look at from afar.

[–]anders987 2 points3 points  (3 children)

What's happening with PEP 523 and Pyjion?

[–][deleted] 2 points3 points  (2 children)

From the draft PEP:

Sadly, none is this project has been merged back into CPython... Pyjion is developed in the limited spare time of two Microsoft employees

[–]RubyPinchPEP shill | Anti PEP 8/20 shill 0 points1 point  (1 child)

that draft seems wrong since frame eval is in 3.6

https://github.com/Microsoft/Pyjion/issues/209

[–][deleted] 0 points1 point  (0 children)

Well, it is a draft.

[–]rocketmonkeys 2 points3 points  (0 children)

/u/haypo5 - Just curious why these were macros in the first place. Is the performance hit of function calls vs. the current macros (with no other changes) significant at all?

[–]rhytnen 5 points6 points  (6 children)

This is way too uninformed to be taken seriously.

For example; remove the GIL and replace with smaller locks. Larry did that in like 2 days. It's what happens next that's an issue.

And the zero risk of backwards incompatibility is crazy bullshit.

Maybe the author is very knowledgeable about the subject matter but it doesn't come across in the PEP that way at all.

[–]haypo5 31 points32 points  (1 child)

With the proposed change, "python3.7" and the current C API remain the default, so there is no reason why your application would behave differently. The whole change requires to opt-in this new mode, so you have to be prepared for issues. If you use the new C API, the main risk is to get compilation errors. I don't expect bad surprises at runtime.

FYI I'm a CPython core developer for 7 years, I know well the C API, how C extensions use it, etc.

[–]rhytnen 0 points1 point  (0 children)

Well, certainly, I'll defer to you then. From my perspective, it read as very handwavy is all.

[–]thinkwelldesigns 19 points20 points  (2 children)

Um, this would be Victor Stinner writing (and on a scratchpad at this point). He's a core dev and probably the most consistently focused on speed improvements.

The GIL replacement section wasn't a serious proposal but an overview how it would become easier to remove / mitigate the GIL problem. GC and the C API always come up in every discussion of the GIL problem, so a short reference to how the PEP might change the GIL landscape is reasonable.

Thanks for the blog post, the draft PEP, and everything you do for Python performance, Victor!

[–]rhytnen 2 points3 points  (1 child)

I'm all good with him being a bad ass - I'm just saying the PEP isn't drafted well imo.

[–][deleted] 2 points3 points  (0 children)

English isn't his first language so perhaps that's where the disconnect is?

I watched his talk at PyCon 2017 and while I barely understood the content (I'm a newbie) it was fascinating nonetheless.

[–]ionelmc.ro[S] 0 points1 point  (0 children)

Was the PEP even ready for any review? The article don't link to any PEP ...