Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python JIT project was asked to pause development

discuss.python.org

Post reply on HN
Print view View original

101–105 of 105 posts

Re: Python JIT project was asked to pause development

#101

Post by germandiago »

germandiago wrote: post #87
IshKebab wrote: post #33

Earlier quoted context omitted.

Right... but it's still only 15% faster than a simpler alternative. In a language that is 50x slower than the alternatives. Clearly not worth it. Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.

When I choose Python for something, it is clearly for its speed. It is nice to have the speed, always. But in Python, it would be a mistake to do it at the expense of flexibility. Same for typing: it is great to have it. I use it. But Python should be dynamic and the rest and extension that does not compromise everything else. If a JIT can make Python 2 or 3x faster, or even 10x for some workloads, that is nice. But…

oh, I meant it is clearly NOT for its speed.

Re: Python JIT project was asked to pause development

#102

Post by scott_w »

dataflow wrote: post #97
scott_w wrote: post #82

Earlier quoted context omitted.

If it’s so easy then writing a PEP and getting it approved in 6 months will be trivial.

"It"? What are you talking about? You didn't answer my question at all. I said if you have a second JIT to swap to in the future , you should be able to switch to that without breaking apps and not be forced to keep this implementation forever -- because JITs don't tend to expose APIs or leaky abstractions to the code, and it's not hard to ensure this one doesn't either. I asked you if you've ever seen another langua…

"It" is the PEP that the Steering Committee are asking for. I'm not on the committee and I don't know how to write a JIT to meet the requirements.

What I don't understand is "what is your position?" Is is that writing a PEP is unnecessary because adding a JIT to Python could trivially meet the goals you state?

My position is simple: adding a JIT is a major change to the language, so of course it should undergo a PEP and answer the major questions that the steering committee put forward. If you think those questions are trivial, then that's ok. Just answer them in the PEP.

> And if it has to be approved by someone who responds like this, it clearly wouldn't be fun either.

I really don't see why you'd think I would be representative of the steering committee's opinions or attitudes. Do I share a name with one of the members?

Re: Python JIT project was asked to pause development

#103

Post by tasuki »

LtWorf wrote: post #99
tasuki wrote: post #98

Earlier quoted context omitted.

Yes I know as much, but why? Is it for speed? Python is slow anyway, so no big deal. Incompetence? Malice perhaps?

It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then. It's not really a design choice. If you declare a function inside a for loop with the default argument set to a list, it will be re-declared at every iteration of the loop and the list of the default argument will be a new instance every time.

> It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then.

I understand as much.

> It's not really a design choice.

That explains it then. Pretty damning though, no?

Re: Python JIT project was asked to pause development

#104

Post by NekkoDroid »

tasuki wrote: post #103
LtWorf wrote: post #99

Earlier quoted context omitted.

It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then. It's not really a design choice. If you declare a function inside a for loop with the default argument set to a list, it will be re-declared at every iteration of the loop and the list of the default argument will be a new instance every time.

> It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then. I understand as much. > It's not really a design choice. That explains it then. Pretty damning though, no?

I don't have any evidence for my theory, but I assume it is because arguments are processed mostly on the function side instead of the call site.

My assumption just makes sense when all the function really gets is "a list of positional arguments and a dict of keyword arguments" (ala `*args, **kwargs`) that is "deconstructed" to the named variables on the function side. Then the function never gets the default value passed and fills it in before executing the body. Therefore it needs some value to assign and that value is determined when parsing the function definition.

So effectively I want to say that I think instead of the default value being passed at the call site (which is how C++ for example does it by inserting the expression inplace of a specified value) it is filled in by the function before executing the body.

In the end this is just a guess, but that is my working hypothesis.

Re: Python JIT project was asked to pause development

#105

Post by ptx »

NekkoDroid wrote: post #104
tasuki wrote: post #103

Earlier quoted context omitted.

> It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then. I understand as much. > It's not really a design choice. That explains it then. Pretty damning though, no?

I don't have any evidence for my theory, but I assume it is because arguments are processed mostly on the function side instead of the call site. My assumption just makes sense when all the function really gets is "a list of positional arguments and a dict of keyword arguments" (ala `*args, **kwargs`) that is "deconstructed" to the named variables on the function side. Then the function never gets the default value p…

Function definitions in Python are just statements that are executed. When you execute the "def" statement, the default values are evaluated.

You can try it in the REPL:

  >>> def f(foo=print("Executing def statement!")):
  ...   print("Executing function body.")
  ... 
  Executing def statement!
  >>> f()
  Executing function body.
There's a fairly straight-forward explanation of this in the documentation: https://docs.python.org/3/reference/compound_stmts.html#func...

"Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call."

Post reply on HN