Python-ideas July 2020

python-ideas@python.org

93 participants
63 discussions

Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
by Jonathan Fine 05 Aug '20

05 Aug '20

Hi Rob You wrote: So: You're asking that the bytecode generated for the for-loop depends > on something that happens (or not) after the end of the for-loop body > (which could be arbitrarily long). > > I speak from ignorance, but I suspect that even with the new parser, > which I am reliably informed can make the tea and implement world peace, > that would be asking a lot. > I'm also speaking from ignorance. However, here I'm the optimist. Ignorance is bliss. You're the pessimist. The devil is in the details. Until we have knowledge and wisdom on this, I think we need both points of view. So I'm grateful for your https://en.wikipedia.org/wiki/Grain_of_salt (American English, pinch of salt in British English). I hope it makes my dish taste better! -- Jonathan

4 4

How to prevent shared memory from being corrupted ?
by Vinay Sharma 04 Aug '20

04 Aug '20

Problem: Currently, let’s say I create a shared_memory segment using mulitprocessing.shared_memory.SharedMemory <https://docs.python.org/3.10/library/multiprocessing.shared_memory.html> in Process 1 and open the same in Process 2. Then, I try to write some data to the shared memory segment using both the processes, so for me to prevent any race condition (data corruption), either these operations must be atomic, or I should be able to lock / unlock shared memory segment, which I cannot at the moment. I earlier posted a solution <https://mail.python.org/archives/list/python-ideas@python.org/thread/X4AKFF…> to this problem, which received positive response, but there weren’t many responses to it, despite the fact this problem makes shared_memory practically unusable if there are simultaneous writes. So, the purpose of this post is to have discussion about the solution of the same. Some Solutions: 1. Support for shared semaphores across unrelated processes to lock/unlock shared memory segment. --> More Details <https://mail.python.org/archives/list/python-ideas@python.org/thread/X4AKFF…> 2. Let the first bit in the shared memory segment be the synchronisation bit used for locking/unlocking. --> A process can only lock the shared memory segment if this bit is unset, and will set this bit after acquiring lock, and similarly unset this bit after unlocking. Although set/unset operations must be atomic. Therefore, the following tools can be used: type __sync_add_and_fetch (type *ptr, type value, ...) type __sync_sub_and_fetch (type *ptr, type value, ...) type __sync_or_and_fetch (type *ptr, type value, ...) Documentation of these can be found at below links: https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#g_t_005f_00… <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#g_t_005f_00…> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_… <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_…> Any other ideas/solutions are very welcome.

6 20

Thoughts about implementing object-compare in unittest package?
by Henry Lin 29 Jul '20

29 Jul '20

Hey all, What are thoughts about implementing an object-compare function in the unittest package? (Compare two objects recursively, attribute by attribute.) This seems like a common use case in many testing scenarios, and there are many 3rd party solutions solving the same problem. (Maybe we can promote standardization by implementing it in the standard library?) Apologies ahead of time if this idea has already been proposed; I was not able to find similar posts in the archive. Best, -Henry

10 24

Alternative syntax for Callable type-hinting
by Thiago Carvalho D' Ávila 28 Jul '20

28 Jul '20

Hello, The idea here is to use the same operator already used to type-hint the return of functions `->` to define the return of a Callable. * Current syntax: Callable[[ArgumentList], ReturnType] eg. def x(method: Callable[[int, dict], None]) -> None: pass * Proposed syntax: Callable[ArgumentList] -> ReturnType eg. def x(method: Callable[int, dict] -> None) -> None: pass Do you think this is more intuitive? Is it viable? Kind regards, Thiago

2 2

Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
by Jonathan Fine 28 Jul '20

28 Jul '20

Thank you Rob, for your contribution. I find it very helpful. You've raised important implementation questions. Regarding the no-iterations case. Suppose we have for i in items: loop_body case: zero: print('no items to process') In this case, the Python compiler knows that the post-iteration block contains a 'zero:' statement. And in other cases it knows that it does not. So why not have the compiler produce bytecode that records this fact. (This could be done by providing an additional bytecode, or if there's room adding a flag to an existing bytecode.) Depending on how we choose to implement, if we wish we could keep both the bytecode and interpreter code exactly the same, for the currently allowed post-iteration blocks. I apologize that it wasn't clear to you from my example code, that for example we allow any identifier as the 'label argument' in a break statement. As in break error_1 break error_2 break time_out The compiler can and I think should ensure that all labels in the post-iteration block occur in the iteration block. And a code analysis code aka linter should warn about unreachable code. This unreachable code should, of course, not generate any bytecode. Thank you again for your comment. I hope this helps. -- Jonathan

1 0

PEP8 update: using typing.TypeVar before function defenition
by Nikita Serba 27 Jul '20

27 Jul '20

Hello! According to PEP8, there should be 2 blank lines before the function definition. But, I think in case of defining new typing.TypeVar, that will be used only in one function definition, it would be better to put it right before the function definition, i.e. with no blank lines. So I suggest to update PEP8, so it'd recommend skipping blank lines in this case. Thank you for your attention and sorry for my bad English. Sincerely yours, Nikita Serba.

1 0

Faster object representation for UIs
by Gábor Bernát 26 Jul '20

26 Jul '20

Hello, I'd like to bring to your attention https://bugs.python.org/issue41383. The core idea here is per Elizaveta Shashkova: I would like to have a lazy repr evaluation for the objects! Sometimes users have many really large objects, and when debugger is trying to show them in Variables View (=show their string representation) it can takes a lot of time. We do some tricks, but they not always work. It would be really-really cool to have parameter in repr, which defines max number of symbols we want to evaluate during repr for this object. Maybe repr is not the best here, because that should be interpreter meaningful, but instead the __str__ method that's better for this. Maybe we could pass in an optional limit argument to these methods, so that the user can decide what to print depending on how many characters he has left? Any takes, better ideas how we could help this problem? Thanks, Bernat

14 16

New clause in FOR and WHILE instead of ELSE
by Олег Комлев 25 Jul '20

25 Jul '20

ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead: if COND: ... [elif COND: ...] [else: ...] This IF-clause like must be immediately after FOR- or WHILE-cycle (only comment allowed between). It looks like a regular IF, but COND is special. COND may be "break", "pass" or "finally". "if break:" - if used break-operator to exit cycle. "if pass:" - cycle executed 0 times. "if finally:" - cycle executed 0 or more times ("pass-case" is included in "finally-case"). For compatibility only "else:" means "if finally:". It's compatible enhancement. No new keyword. There can be no combination "break", "pass" or "finally" after "if"/"elif:" in current version. ----------------- This idea was suggested as enhancement issue (https://bugs.python.org/issue41272). Eric V. Smith (eric.smith) advised me to put this on the python-ideas mailing list (https://bugs.python.org/issue41272#msg373486).

25 72

add !p to pprint.pformat() in str.format() an f-strings
by Charles Machalow 25 Jul '20

25 Jul '20

Right now in str.format(), we have !s, !r, and !a to allow us to call str(), repr(), and ascii() respectively on the given expression. I'm proposing that we add a !p conversion to have pprint.pformat() be called to convert the given expression to a 'pretty' string. Calling ``` print(f"My dict: {d!p}") ``` is a lot more concise than: ``` import pprint print(f"My dict: {pprint.pformat(d)}") ``` We may even be able to have a static attribute stored to change the various default kwargs of pprint.pformat().

7 11

Deprecation of Enum members
by s.williamswynn.mail＠gmail.com 25 Jul '20

25 Jul '20

Evening, I have run into a situations when an enum member becomes obsolete. However, I'd like to avoid removing the member from the enum to give time for users to catch up to a libraries core types. I've seen Java has a @Deprecated annotation for their Enums. Python enum's can also set an _ignore_ attribute which will avoid instantiating a member in the list. I've implemented a similar approach to solve deprecating enum members. You can check it out here: https://github.com/foxyblue/cpython/pull/1

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas July 2020