Mailman 3 November 2021 - Python-ideas

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

disallow assignment to unknown ssl.SSLContext attributes
by Thomas Grainger June 10, 2022

June 10, 2022

I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime

13 32

Bringing the print statement back
by Guido van Rossum March 2, 2022

March 2, 2022

In Python 3.10 we will no longer be burdened by the old parser (though 3rd party tooling needs to catch up). One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020, 16:31:17) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. Cannot read termcap database; using … [View More]dumb terminal settings. >>> print 2+2 4 >>> print "hello world" hello world >>> print "hello", input("Name:") Name:Guido hello Guido >>> print 1, 2, 3, sep=", " 1, 2, 3 >>> But wait, there's more! The same syntax will make it possible to call *any* function: >>> len "abc" 3 >>> Or any method: >>> import sys >>> sys.getrefcount "abc" 24 >>> Really, *any* method: >>> class C: ... def foo(self, arg): print arg ... >>> C().foo 2+2 4 >>> There are downsides too, though. For example, you can't call a method without arguments: >>> print <built-in function print> >>> Worse, the first argument cannot start with a parenthesis or bracket: >>> print (1, 2, 3) 1 2 3 >>> C().foo (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: C.foo() takes 2 positional arguments but 4 were given >>> print (2+2), 42 4 (None, 42) >>> C().foo [0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'method' object is not subscriptable >>> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). After all, we currently have a bunch of complexity in the parser just to give a helpful error message to people used to Python 2's print statement: >>> print 1, 2, 3 File "<stdin>", line 1 print 1, 2, 3 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2, 3)? >>> And IIRC there have been a number of aborted attempts at syntactic hacks to allow people to call functions (like print) without parentheses, although (I think) none of them made it into a PEP. The PEG parser makes this much simpler, because it can simply backtrack -- by placing the grammar rule for this syntax (tentatively called "call statement") last in the list of alternatives for "small statement" we ensure that everything that's a valid expression statement (including print() calls) is still an expression statement with exactly the same meaning, while still allowing parameter-less function calls, without lexical hacks. (There is no code in my prototype that checks for a space after 'print' -- it just checks that there's a name, number or string following a name, which is never legal syntax.) One possible extension I didn't pursue (yet -- dare me!) is to allow parameter-less calls inside other expressions. For example, my prototype does not support things like this: >>> a = (len "abc") File "<stdin>", line 1 a = (len "abc") ^ SyntaxError: invalid syntax >>> I think that strikes a reasonable balance between usability and reduced detection of common errors. I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo x' and we should only allow dotted names (sufficient to access functions in imported modules and method calls on variables). Or maybe we should only allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or maybe we should really only bring back print statements. I believe there are some other languages that support a similar grammar (Ruby? R? Raku?) but I haven't investigated. Thoughts? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> [View Less]

42 66

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow Feb. 18, 2022

Feb. 18, 2022

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, … [View More]

17 32

Allow syntax "func(arg=x if condition)"
by Peter O'Connor Jan. 19, 2022

Jan. 19, 2022

I often find that python lacks a nice way to say "only pass an argument under this condition". (See previous python-list email in "Idea: Deferred Default Arguments?") Example 1: Defining a list with conditional elements include_bd = True current_way = ['a'] + (['b'] if include_bd else [])+['c']+(['d'] if include_bd else []) new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd] also_new_way = list('a', 'b' if include_bd, 'c', 'd' if include_bd) Example 2: Deferring to … [View More]

6 9

Enhancing iterator objects with map, filter, reduce methods
by Remy Dec. 30, 2021

Dec. 30, 2021

Hi, I'd like to revive this thread after what seemed like a decade and see where this might take us 😃 I like this idea that the OP suggested but I'd like to extend this to all iterator objects (range_iterators, list_iterators etc.). 📌Idea Iterables to expose the .__iter__() method in iterable as .iter(). Iterators to implement 'transformational' functions like map, filter, flat_map, 'reductional' functions like reduce, sum, join, and 'evaluate' functions like to_list and to_set. ( [1,2,… [View More]

15 94

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

Magnitude and ProtoMagnitude ABCs — primarily for argument validation
by kana70416＠gmail.com Nov. 29, 2021

Nov. 29, 2021

Andrew Barnert via Python-ideas writes: ... Is there any commonly used or even imaginable useful type that uses them in weirder ways than set and float (which are both partially ordered) or np? array (where they aren’t even Boolean-values)? I've had occasion (a class for outcomes in two-player games) to define both < and <= as complete preorders, with "symmetry" in the sense that A < B iff B > A and A <= B iff B >= A, but < and <= were completely independent: they … [View More]

1 0

easier writing to multiple streams
by Eyal Gruss Nov. 28, 2021

Nov. 28, 2021

hi first post here :) i have a recurring use pattern where i want to save to file everything i print to the screen. i have used the standard logging module and found it too cumbersome for my simple use case, and i find myself changing all my print()'s to custom myprint()'s. i am interested in suggesting several additions to the standard libraries, as i feel this use case is common enough, important enough, and currently painful enough to justify such changes, and that all four of the following … [View More]

8 8

PEP 671: Syntax for late-bound function argument defaults
by Chris Angelico Nov. 27, 2021

Nov. 27, 2021

Incorporates comments from the thread we just had. Is anyone interested in coauthoring this with me? Anyone who has strong interest in seeing this happen - whether you've been around the Python lists for years, or you're new and interested in getting involved for the first time, or anywhere in between! https://www.python.org/dev/peps/pep-0671/ PEP: 671 Title: Syntax for late-bound function argument defaults Author: Chris Angelico <rosuav(a)gmail.com> Status: Draft Type: Standards Track … [View More]Content-Type: text/x-rst Created: 24-Oct-2021 Python-Version: 3.11 Post-History: 24-Oct-2021 Abstract ======== Function parameters can have default values which are calculated during function definition and saved. This proposal introduces a new form of argument default, defined by an expression to be evaluated at function call time. Motivation ========== Optional function arguments, if omitted, often have some sort of logical default value. When this value depends on other arguments, or needs to be reevaluated each function call, there is currently no clean way to state this in the function header. Currently-legal idioms for this include:: # Very common: Use None and replace it in the function def bisect_right(a, x, lo=0, hi=None, *, key=None): if hi is None: hi = len(a) # Also well known: Use a unique custom sentinel object _USE_GLOBAL_DEFAULT = object() def connect(timeout=_USE_GLOBAL_DEFAULT): if timeout is _USE_GLOBAL_DEFAULT: timeout = default_timeout # Unusual: Accept star-args and then validate def add_item(item, *optional_target): if not optional_target: target = [] else: target = optional_target[0] In each form, ``help(function)`` fails to show the true default value. Each one has additional problems, too; using ``None`` is only valid if None is not itself a plausible function parameter, the custom sentinel requires a global constant; and use of star-args implies that more than one argument could be given. Specification ============= Function default arguments can be defined using the new ``=>`` notation:: def bisect_right(a, x, lo=0, hi=>len(a), *, key=None): def connect(timeout=>default_timeout): def add_item(item, target=>[]): The expression is saved in its source code form for the purpose of inspection, and bytecode to evaluate it is prepended to the function's body. Notably, the expression is evaluated in the function's run-time scope, NOT the scope in which the function was defined (as are early-bound defaults). This allows the expression to refer to other arguments. Self-referential expressions will result in UnboundLocalError:: def spam(eggs=>eggs): # Nope Multiple late-bound arguments are evaluated from left to right, and can refer to previously-calculated values. Order is defined by the function, regardless of the order in which keyword arguments may be passed. Choice of spelling ------------------ Our chief syntax proposal is ``name=>expression`` -- our two syntax proposals ... ahem. Amongst our potential syntaxes are:: def bisect(a, hi=>len(a)): def bisect(a, hi=:len(a)): def bisect(a, hi?=len(a)): def bisect(a, hi!=len(a)): def bisect(a, hi=\len(a)): def bisect(a, hi=`len(a)`): def bisect(a, hi=@len(a)): Since default arguments behave largely the same whether they're early or late bound, the preferred syntax is very similar to the existing early-bind syntax. The alternatives offer little advantage over the preferred one. How to Teach This ================= Early-bound default arguments should always be taught first, as they are the simpler and more efficient way to evaluate arguments. Building on them, late bound arguments are broadly equivalent to code at the top of the function:: def add_item(item, target=>[]): # Equivalent pseudocode: def add_item(item, target=<OPTIONAL>): if target was omitted: target = [] Open Issues =========== - yield/await? Will they cause problems? Might end up being a non-issue. - annotations? They go before the default, so is there any way an anno could want to end with ``=>``? References ========== Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. [View Less]

31 292

Should bare logical comparisons raise a warning?
by ehmatthes＠gmail.com Nov. 26, 2021

Nov. 26, 2021

Hi everyone, I've been really impressed by the recent improvements to error messages in Python 3.10. The specific suggestions in some error messages are going to save countless hours of people's time. The benefits for beginners are fairly obvious. But even for experienced programmers, the difference between seeing a missing colon in an error message and just adding it where it should have been vs spending 30 seconds or a minute figuring out what's missing at the start of a loop adds up. One … [View More]

6 6

Re: extending ast.parse with some lib2to3.pytree features
by Neil Girdhar Nov. 22, 2021

Nov. 22, 2021

I wish this had gotten more attention! :)

3 2

Python Developer’s Guide chinese version
by zhouwenbonwpu＠mail.nwpu.edu.cn Nov. 22, 2021

Nov. 22, 2021

hi all, I want to know does Python Developer’s Guide have chinese version, If not, i want to do some translation, may i tell to PSF(or other people) to grant authorization? May you also want to do this translation, please contact me. Best, bobozi

4 6

Runtime-accessible attribute docstrings
by tmkehrenberg＠gmail.com Nov. 20, 2021

Nov. 20, 2021

Hi all, I have seen discussion of docstrings for class attributes before on this list, but not with this exact proposal. My motivation is that I have a dataclass for which I want to write docstrings that can be accessed at runtime. In my specific case, the docstrings would be used to create a help message. Sphinx supports a syntax to document class attributes. It looks like this: @dataclass class A: """Docstring for class A.""" x: int """Docstring for x""" y: bool = True … [View More]

11 16

Recursive submit in concurrent.future.ProcessPoolExecutor
by Evan Greenup Nov. 19, 2021

Nov. 19, 2021

Hi, Currrently, is it allowed for process worker to submit new task to its parent executor? Considering the following Python script: ```python3 import concurrent.futures with concurrent.futures.ProcessPoolExecutor(max_workers=12) as ppe: def hello(n: int) -> int: if n == 0: return 0 return n+ ppe.submit(hello, n-1).result() future = ppe.submit(hello, 1) print(future.result()) ``` It will never stuck and never ended. Sent with [ProtonMail](https://protonmail.com/) Secure Email.

1 0

Adding pep8-casing-compliant aliases for the entire stdlib
by Matt del Valle Nov. 18, 2021

Nov. 18, 2021

So I was reading the docs for the `threading` module and I stumbled upon this little note: Note: In the Python 2.x series, this module contained camelCase names for some methods and functions. These are deprecated as of Python 3.10, but they are still supported for compatibility with Python 2.5 and lower. And it got me thinking. Given that there is some precedent, would it be feasible to make a concerted effort to add aliases across the board for all public-facing stdlib types and … [View More]functions that don't follow pep8-recommended casing? I realize that large chunks of the stdlib predates pep8 and therefore use various non-uniform conventions. For example, the logging module is fully camelCased, and many core types like `str` and `list` don't use PascalCase as pep8 recommends. The `collections` module is a veritable mosaic of casing conventions, with some types like `deque` and `namedtuple` being fully lowercased while others like `Counter` and `ChainMap` are PascalCased. My motivation for this twofold: 1) I'll confess that this has just always been a wart that has bothered me way more than it has any right to. I just *hate* it. Somewhere deep inside my lizard-brain it makes me unhappy to have disparate naming conventions in my code. I realize this isn't a good reason in and of itself but I wonder if this might not be the case for others as well. While I've come to accept it because that's just how it is, maybe it doesn't have to be this way? 2) It's always been an extra thing to explain when teaching python to someone. I always try to cover pep8 very early to discourage people I'm training from internalizing bad habits, and it means you have to explain that the very standard library itself contains style violations that would get flagged in most modern code reviews, and that they just have to keep in mind that despite the fact that the core language does it, they should not. So the scope of my suggestion is as follows: - lowercase types become PascalCase (e.g., `str` -> `Str`, `collections.defaultdict` -> `collections.DefaultDict`) - lowercase attributes/functions/methods become snake_case (no changes for names that only contain a single word, so `str.lower()` would be unaffected, but `str.removeprefix()` would get the alias `str.remove_prefix()`) - pep8 and the python docs are updated to state that the pep8-compliant forms of stdlib names should be strongly preferred over the legacy names, and that IDEs and linters should include (configurable?) weak warnings to discourage the use of legacy-cased stdlib names - `help()` would be special-cased for builtin types to no longer display any current non-pep8-compliant names, and the python docs would also no longer show them, instead only making a note at the top of the page as with the `threading` module. Given the horrors of the python 2.7 schism I don't think there's any rush to officially deprecate or remove the current non-pep8 names at all. I think that's the sort of thing that can happily and fully be kicked down the road. If we add aliases and they see widespread adoption to the point where the non-pep8 forms are barely ever even seen out in the wild then maybe in 10 or 20 years time when the steering council is deliberating on a new major python version they can consider rolling the removal of legacy badly-cased names into it. And if not then no big deal. So yeah, thoughts? [View Less]

21 30

Make the global/nonlocal keyword a prefix
by Jonathan Sh. Nov. 17, 2021

Nov. 17, 2021

Usually when we want to make a variable/def/class etc global, we can just declare `global v` at the beginning, but I feel like there could be a better way to do that. So my idea is to allow doing stuff like `global a = 3` or `nonlocal def x(): ...` or even `for global i in []: ...` in addition to the current `global` statement to allow backwards compatibility What do you think?

5 6

Generic Type Parameters
by Abdulla Al Kathiri Nov. 16, 2021

Nov. 16, 2021

Hello, Instead of writing 'class A(Generic[T]): ...', can we do something like rust lang, i.e., 'class A[T]: ...'? Rust uses <T> but in python we use [T]. This reflects the type annotation for the class nicely. For example, a: A[T]. It’s weird seeing the word Generic inside the class inheritance parentheses which should be reserved for abstract base classes (abc) or explicit protocol classes or superclasses in general (even with their generic type parameters. For example, class A[T](… [View More]Sequence[T]). Rust also defines the generic type parameter for functions. “fn func<T>(a: A[T]) -> T {function body}”. In Python, we can do the following: def func[T](a: A[T]) -> T: … With the new proposed type hint for Callable, The type annotation for the above function will be .. func: [T](A[T]) -> T And this as well reflects nicely with the function signature. Now, suddenly, we don’t need to write 'T=TypeVar(“T”, bound=…,)' if the generic type is enclosed for the class and function scopes (local not global) as in rust. "class A[T]: ...” can be thought of as a syntactic sugar for "class A(Generic[TypeVar(“T”)]): … “ . If the generic type implements a protocol or inherits from a base class, then we can do something like the following: @dataclass class A[T, U: Container[T]]: attr1: T attr2: U def check_all(self, x: T, container: U) -> bool: return (self.attr1 in self.attr2) and (x in container) here the T has no bounds nor constraints. It can be anything, but the U has to implement the Container protocol of type T. Lets create a function and see how we are going to use the class A above.. def test_function[T, U: Container[T]](a: A[T, U], x: T, container: U) -> bool: return a.check_all(x, container) a1 = A(10, [1, 2, 10]) # Valid creation since [1, 2, 10] is a Container[int] a2 = A(10, [“aa", “bb", “cc"]) # Not Valid, attr1: int, but attr2 is not Container[int] a3 = A(10.0, {1.0, 2.0, 10.0}) # Valid since {1.0, 2.0, 10.0} is a Container[float] test_function(a1, 3, [1, 5, 3]) #Valid test_function(a1, 3, {1, 5, 3}) # Not Valid The last one will be valid if the function signature were like the following: def test_function[T, U: Container[T]](a: A[T, U], x: T, container: Container[T]) -> bool: … because the the container argument (set[int]) does not need to be the same as U in a1 (list[int]). In Rust, they use the keyword “where” if the generic type parameters are long. I don’t know how we can do something similar in Python. Maybe like this? def test_function[T, U, V]( a: A[T, U], x: T, container: U, y: V ) -> bool: where ( U: Container[T], V: Sized + RandomProtocol, #suppose RandomProtocol has “random" method ) print(f”variable y size is {len(y)} and the random numbers are {y.random()}") return a.check(x, container) #### The + sign is to bound V further. That’s how rust does it. Think of intersection (Sized & RandomProtocol) as opposed to union. It could support multiple inheritance. To completely mimic TypeVar, we need to think of the constraints *args and the covariant and contravariant parameters. Maybe something like the following format: T: Bound(s) = constraint1 | constraint2 ... # T is invariant, e.g., "AnyStr = str | byte" has no bounds/abc/protocols, it has only constraints T<: Bound(s) = constraint1 | constraint2 … # T is covariant T>: Bound(s) = constraint1 | constraint2 … # T is contravariant U: Bound(s) = default_generic_type For the default type, this example illustrates it: class AddProtocol[T=Self, U=Self](Protocol): def __add__(self, other: T) -> U: … class GreaterProtocol[T=Self](Protocol): def __gt__(self, other: T) -> bool: ... @dataclass class Test[U]: where U: AddProtocol + GreaterProtocol = int #here we didn’t need to write AddProtocol[V, W] or GreaterProtocol[V] because they take default parameter Self (which is U in this case) for the generic types attr: U Also the below function does not need to define the generic parameter U if int is wanted def func_generic[U: AddProtocol + CompareProtocol](test1: Test[U], test2: Test[U]) -> tuple[U, bool]: addition = test1.attr + test2.attr comparison = test1.attr > test2.attr return addition, comparison def func_int(test1: Test, test2: Test) -> tuple[int, bool]: … test_int_1 = Test(1) test_int_2 = Test(2) test_str_1 = Test(“hello ”) test_str_2 = Test(“world”) func_generic(test_int_1, test_int_2) # Valid func_int(test_int_1, test_int_2) # Valid func_generic(test_str_1, test_str_2) # Valid func_int(test_str_1, test_str_2) # Invalid [View Less]

1 0

Unpacking in tuple/list/set/dict comprehensions
by Erik Demaine Nov. 14, 2021

Nov. 14, 2021

Extended unpacking notation (* and **) from PEP 448 gives us great ways to concatenate a few iterables or dicts: ``` (*it1, *it2, *it3) # tuple with the concatenation of three iterables [*it1, *it2, *it3] # list with the concatenation of three iterables {*it1, *it2, *it3} # set with the union of three iterables {**dict1, **dict2, **dict3} # dict with the combination of three dicts # roughly equivalent to dict1 | dict2 | dict3 thanks to PEP 584 ``` I propose (not for the first time) that … [View More]similarly concatenating an unknown number of iterables or dicts should be possible via comprehensions: ``` (*it for it in its) # tuple with the concatenation of iterables in 'its' [*it for it in its] # list with the concatenation of iterables in 'its' {*it for it in its} # set with the union of iterables in 'its' {**d for d in dicts} # dict with the combination of dicts in 'dicts' ``` The above is my attempt to argue that the proposed notation is natural: `[*it for it in its]` is exactly analogous to `[*its[0], *its[1], ..., *its[len(its)-1]]`. There are other ways to do this, of course: ``` [x for it in its for x in it] itertools.chain(*its) sum(it for it in its, []) functools.reduce(operator.concat, its, []) ``` But none are as concise and (to me, and hopefully others who understand * notation) as intuitive. For example, I recently wanted to write a recursion like so, which accumulated a set of results from within a tree structure: ``` def recurse(node): # base case omitted return {*recurse(child) for child in node.children} ``` In fact, I am teaching a class and just asked a question on a written exam for which several students wrote this exact code in their solution (which inspired writing this message). So I do think it's quite intuitive, even to those relatively new to Python. Now, on to previous proposals. I found this thread from 2016 (!); please let me know if there are others. https://mail.python.org/archives/list/python-ideas@python.org/thread/SBM3LY… There are several arguments for and against this feature in that thread. I'll try to summarize: Arguments for: * Natural extension to PEP 448 (it's mentioned as a variant within PEP 448) * Easy to implement: all that's needed in CPython is to *remove* some code blocking this. Arguments against: * Counterintuitive (to some) * Hard to teach * `[...x... for x in y]` is no longer morally equivalent to `answer = []; for x in y: answer.append(...x...)` (unless `list1.append(a, b)` were equivalent to `list1.extend([a, b])`) Above I've tried to counter the first two "against" arguments. Some counters to the third "against" argument: 1. `[*...x... for x in y]` is equivalent to `answer = []; for x in y: answer.extend(...x...)` (about as easy to teach, I'd say) 2. Maybe `list1.append(a, b)` should be equivalent to `list1.extend([a, b])`? It is in JavaScript (`Array.push`). And I don't see why one would expect it to append a tuple `(a, b)`; that's what `list1.append((a, b))` is for. I think the main argument against this is to avoid programming errors, which is fine, but I don't see why it should hold back an advanced feature involving both unpacking and comprehensions. Erik -- Erik Demaine | edemaine(a)mit.edu | http://erikdemaine.org/ [View Less]

15 30

[Python-Dev] Adding pep-8-casing-compliant aliases for unittest and logging
by Ethan Furman Nov. 13, 2021

Nov. 13, 2021

On 11/11/21 11:53 AM, Matt del Valle wrote: > Okay, so from the replies so far it looks like this is very quickly going into the 'never gonna happen' > dumpster, so in the interests of salvaging *something* out of it: [...] > I just dislike having to settle for 'it's what we've got'. With these two modules in particular, a lot > of the arguments that have been made so far either don't apply or are not as strong (such as the > confusion of having builtins.list, builtins.List … [View More]

6 9

request for new Executor in `concurrent.futures`
by Evan Greenup Nov. 8, 2021

Nov. 8, 2021

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 … [View More]

2 1

pickling decorated function
by Evan Greenup Nov. 8, 2021

Nov. 8, 2021

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 Nov. 6, 2021

Nov. 6, 2021

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 … [View More]

3 2

Beginners accidentally shadow module names due to different expectation of the resolution order for module imports
by Florian Wetschoreck Nov. 4, 2021

Nov. 4, 2021

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 … [View More]

5 6

Print and eval
by Evan Greenup Nov. 2, 2021

Nov. 2, 2021

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