Mailman 3 November 2021 - Python-ideas

request for new Executor in `concurrent.futures`
by Evan Greenup 08 Nov '21

08 Nov '21

Currently, There is two types of Executor in `concurrent.futures`. They are `ThreadPoolExecutor` and `ProcessPoolExecutor`, there is GIL limitation of `ThreadPoolExecutor` and `ProcessPoolExecutor` need to use `pickle` which have limitation on decorated function. It would be nice to add new Executor `UnixForkExecutor` which is based on `os.fork` and shared memory (to return future). The drawback of UnixForkExecutor can only be used on Unix platform. This is not a problem, because the majority people use python for parallel computing on Unix platform. Anyone have any opinion about it?

2 1

pickling decorated function
by Evan Greenup 08 Nov '21

08 Nov '21

Currently pickling decorated function is impossible due to name collision. Because the decorated function is what we want, so it would be nice to add syntax sugar in Python to automatically rename original function with random generated prefix or suffix. This can greatly help the application of parallel computing.

1 0

Call two or more functions with one args
by one last Day 05 Nov '21

05 Nov '21

Call two or more functions with one args. one last Day إلى python-dev-owner قبل 7 أيام التفاصيل #While reading about functions in mathematics, a figure representing the sum of two functions caught my attention. #I found it would be useful to add it in the next version of Python. Of course, what is meant by collecting the two functions in mathematics is to collect the results of the two functions, but here I mean to collect the two or more functions on one args. #If all the added functions have the same parameter and the same number of them, then the form x = multi (fun1,func2)(3.5) will be very useful def multi (a,b,s): #func to return multi func with one arg or multi args #Operations are performed on all parematers that represent functions using one args, with the condition that all functions accept the same number of variables #In this case, it is just a function that we want to develop to avoid possible errors and build several scenarios #It has to be something like that # x = multi (func1,func2)(3.5) # and return list of func results or None for func with None return # print(x[0], x[1]) a1 = a(s) b1 = b(s) return ([a1,b1]) def a (s): #print(s) return s def b (s): #print(s+1) return s+1 x = multi(a,b,2) print(x[0], x[1])

3 2

Beginners accidentally shadow module names due to different expectation of the resolution order for module imports
by Florian Wetschoreck 03 Nov '21

03 Nov '21

Hello everyone: The scenario/observation: Beginners sometimes create scripts with the name of a package e.g. pandas.py or seaborn.py in order to test something. Later, they create and run another script or Jupyter Notebook in the same folder which contains e.g. "import seaborn as sns" where the import itself (most often) succeeds. However - and you see that coming already - when they try to use attributes of the module, this fails with an AttributeError and the poor souls don't know what happened and are not familiar and confident enough to walk the traceback to find out that the import was resolved by the local seaborn.py file instead of the installed seaborn module/library. They are blocked until they have access to a senior Pythonista who helps them out with that or they understand the Stackoverflow advice even though they think the solution should come from a different direction. Either way, *it does not make Python seem seamless and intuitive to them*. (And the next time around, they might have forgotten about this idiosyncrasy and go through the loop again - especially if they don't code on a daily basis which - in my experience - is the fact for a significant number of casual Python users.) The problem: *Their internal mental model / expectation is that this import name should (first) relate to the installed library - rather than the local file that happens to live in the (often messy) same folder.* Having said that, I guess that this has been discussed already in the past and I am curious about any pointers to discussions of the past. (I searched for "import order modules" in the archive and could not find something similar in the first 10 results.) Have a great day, Florian PS: I guess, one potential solution would be to change the import resolution order. But of course, this is a breaking change (at least in implicit semantics - not sure if it will actually lead to too many real-world problems - but probably there will be some) and might only be feasible in a safe way in a new major version? (Or even in a minor version but with other flags or imports from "the past" instead of "future" that restore the old behavior if that is actually important for some users?)

5 6

Print and eval
by Evan Greenup 01 Nov '21

01 Nov '21

It would be nice to add the following syntax sugar in Python "Print and Eval" like `ptev a == b` It is same as `statement = "a == b"; print(f"{statement} ? {eval(statement)}")`. It would super nice for debugging and other research project.

4 3

PEP 671 proof-of-concept: A less invasive implementation
by Jonathan Fine 31 Oct '21

31 Oct '21

Hi One of the motives for PEP 671 is that the signature of a function fn, and hence the associated help(fn) is sometimes opaque regarding default values. I won't repeat the excellent examples already given. In the current implementation default values are handled outside the compiled code of the function, which is available at fn.__code__. Instead they are stored in 'metadata' associated with the function. Here's one way to see this. from inspect import signature as sig def fn(a, b=1, c=2): return a, b, c sig(fn) # Gives <Signature (a, b=1, c=2)> fn.__defaults__ = ('hi', 'there') sig(fn) # Gives <Signature (a, b='hi', c='there')> We can also change the __code__ object, but care is needed here. def gn(): return (1, 2, 3) fn.__code__ = gn.__code__ fn() # Gives (1, 2, 3). sig(fn) # Gives <Signature ()> fn.__defaults__ # Gives ('hi', 'there') The signature of fn, together with the arguments actually supplied, is used to initialise the code frame which is put on the top of the stack, and in which fn.__code__ executes. I suggest that an implementation which provides additional flexibility in the manner in which the code frame is initialised would be less invasive. Necessarily, PEP 671 allows programmer supplied code to be used in the 'initialisation phase'. The previous attempts place that code in fn.__code__. I suggest that the implementation adds a new attribute fn.__wibble__ to fn, which can either be None or a code object. And if fn.__wibble__ is not None, then it is used to initialise the code frame in which fn.__code__ executes. It would as before take as input the arguments actually supplied by the user. I stop here, saying nothing for now about two important questions. First, what is the programmer syntax for creating such a 'two-part' function fn. Second, what does the user see as a result of help(fn). Or in other words, how to extend the semantics of inspect.signature. with kind regards Jonathan

3 7