Mailman 3 December 2021 - Python-ideas

PEP-671 thread - let's take a break, please.
by C. Titus Brown Dec. 9, 2021

Dec. 9, 2021

Hi all, the PEP-671 thread is starting to accumulate an awful lot of heat. I’ve placed the list into emergency moderation for the day to give everyone a chance to take a step back and (re)consider their next e-mails. Thank you! best, —titus (list moderator)

1 0

PEP 671 review of default arguments evaluation in other languages
by Steven D'Aprano Dec. 7, 2021

Dec. 7, 2021

A woefully incomplete review of default argument evaluation in other languages. Updates and corrections are welcome. Out of 22 languages apart from Python: - 3 use early binding (default is evaluated at compile or function definition time); - 12 use late binding (default is evaluated at call time); - 1 simulates late binding with a standard idiom; - and 6 do not support default arguments. Note that R's model for defaults in particularly interesting. Early binding ------------- PHP:… [View More]

9 23

Re: PEP 671 review of default arguments evaluation in other languages
by Steven D'Aprano Dec. 6, 2021

Dec. 6, 2021

On Mon, Dec 06, 2021 at 10:33:43AM +0100, Piotr Duda wrote: > You can simply write > def func(arg=>FUNC_DEFAULT_VALUE): Doh! Of course you can! I knew that! :-( -- Steve

1 0

Re: PEP 671 (late-bound arg defaults), next round of discussion!
by Steven D'Aprano Dec. 6, 2021

Dec. 6, 2021

On Sun, Dec 05, 2021 at 11:09:47AM -0800, Christopher Barker wrote: > But beyond a certain level of complexity, it shouldn’t be in signature > anyway. And it can only be a single expression anyway. True. But in that case, this PEP doesn't help either. Despite what Chris might think, I like this PEP (in principle, if not in detail) but it does have to be said, it's not exactly useful in many circumstances. You need a default value that is generated at every call, not just once when … [View More]

1 0

Compiler from python to WebAssembly
by Ricard Sanchez Besalduch Dec. 5, 2021

Dec. 5, 2021

Hi It would be cool to make a compiler from python to WebAssembly. Adapting the actual python compiler. And making an interface to interact with the DOM as a python library. The final idea is to replace JavaScript with Python. With that we could use python in the frontend and in the backend, with Django.

2 1

PEP7 may need to add a info
by zhouwenbonwpu＠mail.nwpu.edu.cn Dec. 3, 2021

Dec. 3, 2021

Hi! When I read PEP7 and check Cpython source code, I found a deficiency that in https://www.python.org/dev/peps/pep-0007/#code-lay-out. In this section, document said that ''' For external functions and variables, we always have a declaration in an appropriate header file in the "Include" directory, which uses the PyAPI_FUNC() macro, like this: PyAPI_FUNC(PyObject *) PyObject_Repr(PyObject *); ''' but when i check python 3.7.12+ and python 2.7.13, external variables actually uses the … [View More]

2 1

Official means to release the GIL in Python
by TobiasHT Dec. 3, 2021

Dec. 3, 2021

The GIL has been a widely discussed topic in the Python community. It's has it's advantages and disadvantages. I was suggesting that an official way be placed in the Python threading module to release the GIL if one needs to perform some tasks that don't need the GIL. It could be something as simple as thd = threading.Thread(target = encrypt, nogil = True) I saw a nogil option in Cython, I just thought it would be great to have it fully support in Python as we await the results from Sam Gross's paper.

2 1

Re: PEP 671 (late-bound arg defaults), next round of discussion!
by abed...＠gmail.com Dec. 3, 2021

Dec. 3, 2021

There was a typo in my post and I want to avoid getting into a pedantic tangent about how to properly indent multi-line function signatures, so hopefully this will "nip it in the bud", so to speak. When I wrote: def my_func( param: Annotation[stuff], other_param: MoreAnnotation[things], another_param: SomeType = default_value, yet_another_param: EvenMoreAnnotation = another_default) -> ReturnType: # code goes here ... I meant the … [View More]parameter list to be at two indentation levels so it's visually distinguishable from the function body at one indentation level. I accidentally put the parameter list at three indentation levels which happen to align with the open parentheses after `def my_func` which is not what I wanted to suggest as good practice because then functions with long names would have their parameter list indented way far over and it would hurt readability. The following is closer to what I intended: *def my_func( param: Annotation[stuff], other_param: MoreAnnotation[things], another_param: SomeType = default_value, yet_another_param: EvenMoreAnnotation = another_default) -> ReturnType: # code goes here ...* On Thursday, December 2, 2021 at 5:56:36 PM UTC-6 abed...(a)gmail.com wrote: > If the coder's intent is to have an optional parameter default to an empty >> list, the most EXPLICIT way to encode that intent would be to have the >> optional parameter default to an empty list. It's categorically LESS >> EXPLICIT to bind the parameter to None and add boilerplate code to the body >> of the function to correct that. > > > I think it's a nearly philosophical distinction but right now there is no > such thing as “an optional parameter defaulting to an empty list”. Or > rather there is, but it's not what you really want “a different empty list > for every call of the function”. > > > It's not philosophical. It's pretty cut and dry: If you want a parameter > to default to an empty list, it's objectively more explicit to make the > parameter default to an empty list than to make it default to a sentinel > value and assign it to an empty list later. Of course that capability > doesn't exist yet, that's what this whole discussion is about. > > To me, it's not absurd that “creating a new object and binding the >> parameter to it” is sufficiently complex that we don't cram it into the >> function signature. It's fine to just have code in the function body... > > > It may not be absurd to you, but to me, the function signature is the > correct place to put all things related to the function signature, the > function body is for business logic. You're argument about "cramming things > in the function signature" is more about practical constraints like keeping > things on one line which is less important to me than putting things where > they belong. You can always expand the signature, which is a practice I > wish more people did. > > Instead of this: > > def my_func(param: Annotation[stuff], other_param: MoreAnnotation[things], > another_param: SomeType = default_value, yet_another_param: > EvenMoreAnnotation = another_default) -> ReturnType: > # code goes here ... > > just do this: > > def my_func( > param: Annotation[stuff], > other_param: MoreAnnotation[things], > another_param: SomeType = default_value, > yet_another_param: EvenMoreAnnotation = another_default) -> > ReturnType: > # code goes here ... > > The repulsion against "cram[ing] [defaults] into the function signature" > is more a problem with long function signatures than anything else. You can > always use the usual suspects to make it more readable: > > instead of this: > > def my_func(param: SomeType => long and complicated logic that's hard to > read and fits too much in one line) -> ReturnValue: > ... > > just do this: > > def _provide_default() -> SomeType: > the same logic as above > but more readable > and better organized > > def my_func(param: SomeType => _provide_default()) -> ReturnValue: > ... > > especially since there does not seem to be an overwhelming consensus for >> either the concept or the proposed syntaxes. > > > The above explanation of why it's objectively more explicit is not subject > to the consensus of the python ideas list. It's a refutation of the > argument that current familiar work-arounds are somehow more explicit. That > somehow binding to a sentinel is actually an explicit way of "telling the > function you want it to provide a default value" rather than a work-around > that's so familiar that you no longer even question if it's all that > explicit in the first place. > > (Also maybe not calling what we have been happily (at least for some of >> us) doing for years "a hack" would be a good way to have a more civil >> discussion) > > > Why? It's not a personal attack. The whole point is to prod people into > rethinking what they've become inured to. > > On Thu, Dec 2, 2021 at 3:11 PM Evpok Padding <evpok....(a)gmail.com> wrote: > >> On Thu, 2 Dec 2021, 21:48 abed...(a)gmail.com, <abed...(a)gmail.com> wrote: >> >>> Nicholas Cole >>> "There is nothing that this proposal makes possible that is not already >>> possible with more explicit code." >>> >>> There's nothing any of Python's syntax makes possible that is not >>> already possible with Brainfuck or any other language that's Turing >>> complete. The current hacks used to get around the lack of late-bound >>> optional parameters aren't more explicit. They just require more code. If >>> the coder's intent is to have an optional parameter default to an empty >>> list, the most EXPLICIT way to encode that intent would be to have the >>> optional parameter default to an empty list. It's categorically LESS >>> EXPLICIT to bind the parameter to None and add boilerplate code to the body >>> of the function to correct that. >> >> >> I think it's a nearly philosophical distinction but right now there is no >> such thing as “an optional parameter defaulting to an empty list”. Or >> rather there is, but it's not what you really want “a different empty list >> for every call of the function”. To me, it's not absurd that “creating a >> new object and binding the parameter to it” is sufficiently complex that we >> don't cram it into the function signature. It's fine to just have code in >> the function body, especially since there does not seem to be an >> overwhelming consensus for either the concept or the proposed syntaxes. >> >> (Also maybe not calling what we have been happily (at least for some of >> us) doing for years "a hack" would be a good way to have a more civil >> discussion) >> >> Best >> >> E >> > [View Less]

1 0

Re: PEP 671: Syntax for late-bound function argument defaults
by Chris Angelico Dec. 2, 2021

Dec. 2, 2021

On Thu, Dec 2, 2021 at 12:42 PM David Lukeš <dafydd.lukes(a)gmail.com> wrote: > > > That's an oversimplification: > > > > foo = 42 > > def bar(): > > print(foo) > > foo = 1 > > > > This won't print 42. > > Oh, right. I've run afoul of this in the past, but clearly not often > enough to make it second nature :) Thanks for being helpful! > > I still think nudging people to only refer to previous arguments in > … [View More]

1 0

Re: PEP 671: Syntax for late-bound function argument defaults
by David Lukeš Dec. 1, 2021

Dec. 1, 2021

This was probably mentioned at some point (apologies, can't afford to read the entire thread), but since the issue of left-to-right vs. early-first-then-late binding was hotly debated, I just want to point out that left-to-right better preserves scoping intuitions: foo = 42 def bar(@baz=foo, foo=1): return baz, foo With left-to-right, bar() returns (42, 1) (or whatever other value the foo global currently has). With early-first-then-late, it returns (1, 1). And according to … [View More]the current version of the PEP, it's essentially undefined behavior, though AFAICS, the possibility that baz would take its value from global foo isn't even considered. As a teacher, I'd much rather teach/explain the first option, because in most of Python, you can figure out what value a name refers to by looking to the left and above of where it's used, and if you can't find it in the local scope, check globals. (One prominent place where this doesn't hold is comprehensions/genexprs, which in practice tend to be a learning bump for beginners.) As for errors -- if SyntaxError were used, then the example above would raise it, wouldn't it? Because there's no way to statically determine whether foo might also be a global, in addition to being a function parameter. So there would be no way of having a late-bound parameter take a default from a global, while having an early-bound parameter with the same name as the global. I freely acknowledge you probably won't need this most of the time, but why prohibit it outright (or why make it into undefined behavior, without even considering the global, as the PEP currently does), especially since it aligns with scoping intuitions as outlined above? Finally, as hinted by the example, I'm leaning towards the @ notation. => is pointing in the wrong direction, when programming languages use some kind of arrow-like operator for assignment, it tends to point towards the name, not the value. (I realize this is not really assignment, but the syntactic analogy is clear.) Whereas I can easily see myself telling students that the @ acts as a sort of barrier to eager evaluation/assignment of the default value (as a mnemonic). It could also be written after the =, as in baz=@foo, which reads like a quote operator and is open to future extensions where unary @ could be used to defer evaluation in more places (as some people seem to want -- I personally am wary of quote/eval/substitute shenanigans, such as R has). The barrier mnemonic could remain the same. OTOH, I like the way the prefix is more conspicuous and visually signals that the parameter is special/different right off the bat. The PEP doesn't have any examples of what the syntax for *assigning* late bound arguments is, so I'm assuming there's no special syntax? As in, bar can be called e.g. as bar(1, 2), bar(baz=1, foo=2) or bar(foo=1, baz=2)? That makes sense, but I think it's a small argument in favor of a prefix notation, so that = is kept the same across definitions and calls. Somehow, I would expect my students to be more likely to erroneously think they need to replicate => and call bar as bar(baz=>1), and less likely to write bar(@baz=1), especially with that barrier mnemonic. Just a hunch though. More seriously though, if => ever makes it into Python as the new lambda too, then bar(baz=>1) is a beginner footgun waiting to happen: you probably meant bar(baz=1), but instead, you wrote bar(baz=lambda baz: 1). Whereas bar(@baz=1) remains a harmless SyntaxError (harmless in that it fails early and gives you a good hint as to what's wrong). Best, David [View Less]

2 1

Re: Enhancing iterator objects with map, filter, reduce methods
by Matt D Dec. 1, 2021

Dec. 1, 2021

In your comprehension example, I'm fairly certain the filtering should be on the post incremented remainder [ x+1 for x in [1,2,3] if (x+1) % 2 == 0] I think that is the downside of the comprehension, having to repeat that twice. Maybe you can get around it with := ?? I'm stuck on 3.7 so I don't know for sure.

2 1