[Python-ideas] inline Python functions and methods
The Python community has a 5 year plan to push the limit of speed in Python. One of the things that reduces Python execution speed is calling methods or functions that are not in the nearest scope. My suggestion is to introduce inline functions just as they are in C. They can be defined as global functions or class methods but are created in the scope of the function that is calling it at parsetime. I also don’t think it’ll be hard to adapt. inline functions might look something like: inline def func(): pass inline async def func(): pass inline class Executor: inline def func(): pass For an inline method, the class must be defined as inline as well, in order to bring to scope whatever class variable or method that the inline function might rely on. This is just a suggestion, what do you guys think about it. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7XSAC2STMEU6WJSLP3DGOGJJGG4IUO3L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Tue, Dec 07, 2021 at 06:42:18PM +, Rob Cliffe via Python-ideas wrote: [The other Stephen] > >That's a strawman. The argument is not "Your proposal is good, but > >not perfect, so we reject it." > > That IMO is exactly the argument. It's like saying "I won't buy a car > today because in 10/20/50 years time I can probably buy a driverless one". I think a better analogy for those who reject late-bound defaults but would accept a general deferred evaluation mechanism is: "I won't buy a driverless car today because I have a perfectly good car now, and **driving is not a sufficient burden** that I care for this feature alone. But fully autonomous robots that could drive my car, clean my house, do my chores, now *that's* something I would buy!" [the other Stephen] > > if _*you*_ do this other stuff we would likely support it." > > [My emphasis - RC.] > > You want *Chris* to implement deferred-evaluation objects? Clearly not. It's obvious in context that Stephen is talking about *generic* "you". He's not addressing his comment to Chris. Anyone could read the comment and interpret that "you" as themselves, and respond "What a great idea! I'm going to implement deferred evaluation!". You surely don't imagine that Stephen thinks, or implies, that those who want a generic deferred evaluation feature would reject it if it wasn't done specifically by Chris himself. I know that the Python-Ideas community is changable like the wind and rather mercurial, but we've never yet demanded a feature we want be implemented by a *particular person* or else we will reject it. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RZPRZSGEPDS2WKSKYGFE4U2UDUIDAPQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On 07/12/2021 18:22, Stephen J. Turnbull wrote: Rob Cliffe via Python-ideas writes: > I think you're making my point. *shrug* You wrote "object", I took you at your word. > You're saying that the object part isn't that hard, but other parts of > it are. For values of "hard" == "non-trivial but mostly bikeshedding". I don't think it will be that much harder to get through than Chris's. And in theory it could be easier: it could be implemented with a new builtin such as "quote_expression" that takes a string, and thus needing no new syntax. I actually don't think that will pass, too clumsy to be of practical use. Although it might fly on the same logic as function annotations did: we add the instance flag that says that "this object is a thunk to be evaluated in the current context" and the code in the interpreter that's needed to use it, and postpone syntax until somebody comes up with a really good proposal. In fact, we could combine this strategy with Steven d'Aprano's proposal for a thunk object, in which case Chris doesn't need syntax himself. I'm sure he won't like that, but it's an idea. All this seems like a matter of opinion, on which we shall have to disagree. But ... > And there seems to be no likelihood of anyone tackling it soon. There's no way to judge that. David Mertz might post a PEP tomorrow for all you know. Surely you're pulling my leg. If he had something in the pipeline that would greatly strengthen his argument, we would have heard about it by now. > I can't see the point of rejecting something that provides a > tangible benefit, now, because some fictitious vapourware *might*, > one day, provide another way of doing it. That's a strawman. The argument is not "Your proposal is good, but not perfect, so we reject it." That IMO is exactly the argument. It's like saying "I won't buy a car today because in 10/20/50 years time I can probably buy a driverless one". The basic argument is "Your proposal isn't good enough to deserve syntax for reasons given elsewhere, Er, what reasons? but if_*you*_ do this other stuff we would likely support it." [My emphasis - RC.] You want *Chris* to implement deferred-evaluation objects? Hasn't he done enough? You want him to produce a second PEP and a second reference implementation in competition with his first one? (He has on several occasions mentioned problems that he sees with the idea.) Surely if other people think it's a good idea, it's up to *them* to prove it. If an architect comes up with a plan to redesign a city centre, would you say to him "Now produce a completely different plan, just to show that your first one wasn't great"? Best wishes Rob Cliffe Sure, there's some component of "it might interfere with the general facility, or be a small cognitive burden, a warty technical debt, if the general facility is implemented", but that's only a tiny part of why people opposing the proposal oppose it. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QMGFNU3Z6BCEVZXYEXIY6SXLET2ESEKF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
Rob Cliffe via Python-ideas writes: > I think you're making my point. *shrug* You wrote "object", I took you at your word. > You're saying that the object part isn't that hard, but other parts of > it are. For values of "hard" == "non-trivial but mostly bikeshedding". I don't think it will be that much harder to get through than Chris's. And in theory it could be easier: it could be implemented with a new builtin such as "quote_expression" that takes a string, and thus needing no new syntax. I actually don't think that will pass, too clumsy to be of practical use. Although it might fly on the same logic as function annotations did: we add the instance flag that says that "this object is a thunk to be evaluated in the current context" and the code in the interpreter that's needed to use it, and postpone syntax until somebody comes up with a really good proposal. In fact, we could combine this strategy with Steven d'Aprano's proposal for a thunk object, in which case Chris doesn't need syntax himself. I'm sure he won't like that, but it's an idea. > And there seems to be no likelihood of anyone tackling it soon. There's no way to judge that. David Mertz might post a PEP tomorrow for all you know. > I can't see the point of rejecting something that provides a > tangible benefit, now, because some fictitious vapourware *might*, > one day, provide another way of doing it. That's a strawman. The argument is not "Your proposal is good, but not perfect, so we reject it." The basic argument is "Your proposal isn't good enough to deserve syntax for reasons given elsewhere, but if you do this other stuff we would likely support it." Sure, there's some component of "it might interfere with the general facility, or be a small cognitive burden, a warty technical debt, if the general facility is implemented", but that's only a tiny part of why people opposing the proposal oppose it. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R52DBL4B7P5FPVL4633I2PMBCHVIBHBA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods
On Wed, 1 Dec 2021 at 19:38, Abdulla Al Kathiri wrote: > > number = text -> re.search(pattern1, _) > -> re.search(pattern2, _.group(0)) > -> re.search(pattern3, _.group(1)) > -> float(_.group(0)) > > Yeah that can look ugly I agree (here intentionally the placeholder is > overused). It looks like you could just write as follows without using any placeholder number = text -> (pattern1 -> re.search)().group(0)\ -> (pattern2 -> re.search)().group(1)\ -> (pattern3 -> re.search)().group(0)\ -> float() but anyway, a question seems: once you start chaining applications of functions from the right, might you start wanting assignment (expression) to the right (of an object on the lhs to a variable on the rhs)? I think that could be easier with chained applications from the right for the reader of the code. Best regards, Takuo Matsuoka ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7ABVKI7YBIHLOHAVVWB5USPOGHU4TNUH/ Code of Conduct: http://python.org/psf/codeofconduct/
