Mailman 3 August 2021 - Python-ideas

staticmethod with property
by Henry Harutyunyan Aug. 25, 2021

Aug. 25, 2021

Currently Python does not support using `@staticmethod` decorator along with `@property` decorator. I think that the it currently works is a bit misleading since it will not give an error, but gives the following outcome. ``` class Foo: @staticmethod @property def bar(): return "1" ``` ``` class Foo: @property @staticmethod def bar(): return "1" ``` In wither of the cases the outcome is the following ``` Foo.bar >>> <property at 0x112dbaf40> a = Foo() a.bar >>> <property at 0x112dbaf40> ``` Is there any particular reason for this? Any don't we make it work?

3 2

Re: We should have an explicit concept of emptiness for collections
by Jon Kiparsky Aug. 25, 2021

Aug. 25, 2021

> Numbers in general are useful concepts that help us with real-world > problems, but it's really hard to pin them down. Not that hard, really. A number is just a hackenbush game :) -jpk

2 1

Notation for subscripts: refreshed proposal summary
by Matsuoka Takuo Aug. 24, 2021

Aug. 24, 2021

Dear Developers, Some of you may have noticed I updated my proposal on the subject yesterday. I'm afraid it was too long without a summary, so here is one. I hope this will be helpful to some people. Summary of the refreshed proposal --------------------------------- (1) Simplify the syntax: We wouldn't need the notion of expression list any more, and would be able to use starred expressions at more places. (2) Simplify the syntax about subscription and slicing: A simple new rule describes a well expectable interpretation of natural but currently invalid expressions (mainly those involving stars) which extends the already given interpretation of already valid expressions. (3) There's a difference from PEP 646: Unlike with PEP 646, we won't have e.g., a[*[y]] as a valid expression which is _not_ equivalent to a[y] The origianal post (sorry about its length) can be found at https://mail.python.org/archives/list/python-ideas@python.org/message/BEGGQ… as well as the entire thread at https://mail.python.org/archives/list/python-ideas@python.org/thread/V2WFMN… Note: In the original post, the description of how __getitem__ (etc.) method would be got was not precise. However, I hope what I wrote makes sense for most situations. Best regards, Takuo Matsuoka

1 0

Definition of a starred expression in the Language Reference
by Matsuoka Takuo Aug. 24, 2021

Aug. 24, 2021

Dear developers, According to the Language Reference, a starred expression is defined by starred_expression ::= expression | (starred_item ",")* [starred_item] https://docs.python.org/3/reference/expressions.html#expression-lists However, in view of the definition of an assignment statement assignment_stmt ::= (target_list "=")+ (starred_expression | yield_expression) https://docs.python.org/3/reference/simple_stmts.html#assignment-statements I believe the correct definition actually used is starred_expression ::= expression | (starred_item ",")+ [starred_item] (that is, use "+" instead of "*"). Should it be fixed? Best regards, Takuo Matsuoka

2 2

Notation for subscripts.
by Matsuoka Takuo Aug. 23, 2021

Aug. 23, 2021

Dear Developers, Given a subscriptable object s, the intended rule for the notation for getting an item of s seems that, for any expression {e}, such as "x, ", s[{e}] (i.e., s[x, ] if {e} is "x, ") means the same as s[({e})] (i.e., s[(x, )] in the considered case), namely, should be evaluated as s.__getitem__(({e})) (or s.__class_getitem__(({e})) when that applies). If this is the rule, then it looks simple and hence friendly to the user. However, there are at least two exceptions: (1) The case where {e} is the empty expression "": The expression s[] raises SyntaxError instead of being evaluated in the same way as s[()] is. (2) The case where {e} contains "*" for unpacking: An expression containing the unpacking notation, such as s[*iterable, ] raises SyntaxError instead of being evaluated in the same way as s[(*iterable, )] in this example, is. Are these (and other if any) exceptions justified? If not, I propose having the described rule to have full effect if that would simplify the syntax. This would affect currently working codes which rely on SyntaxError raised in either of the described ways (through eval, exec or import??). I wonder if reliance on SyntaxError in these cases should be supported in all future versions of Python. Best regards, Takuo Matsuoka

6 14

Re: We should have an explicit concept of emptiness for collections
by Finn Mason Aug. 22, 2021

Aug. 22, 2021

While this does comply with "explicit is better than implicit", there's another line of the Zen of Python that this idea definitely violates: "There should be one-- and preferably only one-- obvious way to do it." (Followed by the line "Although that way may not be obvious at first...", which I'd say also applies; after all, the boolean value of a sequence may not be obvious to a new Python programmer.) The way I see it, the issue is a conflict between these two ideas of what Python code should look like. My strong opinion is against adding isempty(); I see no point. Once you learn Python, it makes sense that an empty sequence is False. I think most Python coders learn that early on. We get it. The "if (not) seq" idiom makes sense, especially since everyone has been doing that for the last twenty years. It's readable. If this is about the fundamentally unknowable type of seq, use type hints. And if you really want to be that explicit, use "if len(seq) == 0" (which could be just "if len(seq)" but that's ruins the whole point). I think isempty() doesn't solve problems. It's completely unnecessary. And if it's somehow actually implemented, implement it as a method of sequence types! A built-in function should either be totally necessary (see: print(), input(), all the basic ones you know and love), or at least make a job much easier and more readable (see: zip(), enumerate(), all(), any(), and more). Python may be a language designed to be readable, but even it isn't English and doesn't need to be. -- Finn

1 0

Add .cache and compile_commands.json to .gitignote
by Jack DeVries Aug. 20, 2021

Aug. 20, 2021

Hi All, I use clangd. Clangd creates a .cache directory, and there are also tools for generating a compile_commands.json file which tells clangd how to behave. I did a quick check, and there are no naming collisions with other files in the cpython project. What does everyone think? Can we add these two items to the .gitignore: - `.cache` - `compile_commands.json` -- Thanks! Jack DeVries

3 3

multiprocessing: hybrid CPUs
by c.buhtz＠posteo.jp Aug. 20, 2021

Aug. 20, 2021

Hello, before posting to python-dev I thought is is the best to discuss this here. And I assume that someone else had the same idea then me before. Maybe you can point me to the relevant discussion/ticket. I read about Intels hybrid CPUs. It means there are multiple cores e.g. 8 high-speed cores and 8 low-speed (but more energy efficient) cores combined in one CPU. In my use cases I do parallelize with Pythons multiprocessing package to work on millions of rows on pandas.DataFrame objects. This are task that are not vecotrizable. I simple cut the DataFrame horizontal in pieces (numbered by the available cores). But when the cores are different in there "speed" I need to know that. e.g. with a 16 core CPU where half of the cores low/slow and every core has 1 million rows to work on. The 8 high speed cores are finishing earlier and just waiting untill the slow cores are finished. It would be more efficient if the 8 high speed cores each would work on 1,3 million rows and the low speed cores each on 0,7 million rows. It is not perfect but better. I know that they will not finish all at the same timepoint. But their end time will be closer together. But to do this I need to know the type of the cores. Am I wrong? Are there any plans in the Python development taking this into account? Kind Christian

8 13

Stack-scoped variables
by Paul Prescod Aug. 19, 2021

Aug. 19, 2021

Let's imagine I have an algorithm which depends on a context variable. I write an algorithm (elided below for space) which depends on it. Then I realize that I can improve the performance of my algorithm by using concurrent.futures. But my algorithm will change its behaviour because it does not inherit the context. Simply trying to parallelize an "embarrassingly parallel" algorithm changes its behaviour. What I really want is a stack-scoped variable: a variable which retains its value for all child scopes whether in the same thread or not, unless it is overwritten in a child scope (whether in the same thread or not). from decimal import getcontext import concurrent.futures def my_algorithm(input): # some real algorithm here, which relies on decimal precision return getcontext().prec getcontext().prec = 8 vals = map(my_algorithm, range(0, 10)) print(list(vals)) with concurrent.futures.ThreadPoolExecutor(max_workers=5) as executor: # Start the load operations and mark each future with its URL results = executor.map(my_algorithm, range(0, 10)) print(list(results)) Results: [8, 8, 8, 8, 8, 8, 8, 8, 8, 8] [28, 28, 28, 28, 28, 28, 28, 28, 28, 28]

4 6

New 'How to Write a Good Bug Report' Article for Docs
by Jack DeVries Aug. 18, 2021

Aug. 18, 2021

Hi All! We are trying to replace a link in the official docs which is now broken, but used to link to this article: https://web.archive.org/web/20210613191914/https://developer.mozilla.org/en… Can you offer a suggestion for a replacement? The bad link has already been removed. Also see the bpo: https://bugs.python.org/issue44830 Also see the rather stale discourse post to the same effect as this email (asking for replacement article ideas): https://discuss.python.org/t/alternate-article-for-how-to-wite-good-bug-rep… Thanks! Jack

5 7