Mailman 3 October 2020 - Python-ideas

Add _KB, _MB, _GB to numeric literals
by malincns＠163.com Oct. 14, 2020

Oct. 14, 2020

PEP 515 added underscore to numeric literals, it brings better readability. PEP 515 -- Underscores in Numeric Literals https://www.python.org/dev/peps/pep-0515/ Is it possible to add _KB, _MB, _GB to numeric literals, for example: 200_KB (200*1024) 150_MB (150*1024*1024) 2_GB (2*1024*1024*1024) Do you think it's a good code style?

9 10

I'm no longer a co-author of PEP 637 - keyword args in item access
by Jonathan Fine Oct. 13, 2020

Oct. 13, 2020

Hi The following is copied and pasted from https://github.com/python/peps/pull/1650 Stefano Borini =========== Commit message: PEP 637 I've asked Jonathan Fine to resign as PEP author, and he's agreed to do so. Details in the pull request Pull request comment: Hi Jonathan Thank you for accepting my invitation to be a co-author of PEP 637. I regret that because of disagreeing direction for the PEP I think it best for the community that I ask you to resign as co-author. Thank you for your help === Jonathan Fine =========== Hi Stefano I'm sorry things didn't work out, the way either of us wanted. Yes, there were disagreements! Particularly on python-ideas, involving also PEP sponsor Steve D'Aprano. I'd like the PEP to be improved before it is submitted. Jonathan === with best regards Jonathan

1 0

Introducing array shape in function declaration
by vdimirc＠gmail.com Oct. 9, 2020

Oct. 9, 2020

Hello! I want to discuss one feature for handful working with shapes of array-like objects. If we want to pass arrays to function we can declare their sizes directly with argument declaration: ``` def foo(a[m, n], b[n]): for i in range(m): for j in range(n): a[i, j] = b[j] ``` Will be equivalent to ``` def foo(a, b): m, n = a.__shape__() n_b = b.__shape__() if n_b != n: raise ShapeNotValidException() ... ``` Objects should implement `__shape__` magic method to use this syntax. Shapes automatically introduced to variables and checked. Also we can allow more complex checks, e.g.: ``` def bar(a[2,...]): ... ``` will check that first dimension of passed array equals to 2. Or: ``` def bar(a[n], b[2*n]): # checks that a.__shape__()[0] == 2 * b.__shape__()[0] ... ```

1 0

SupportsString Protocol Type Annotation
by aleksiy123 Oct. 8, 2020

Oct. 8, 2020

Currently there are a few Protocols https://docs.python.org/3/library/typing.html#protocols defined in the typing module. One that I recently felt like was missing was a typing annotation for classes with a __str__() method defined. Seems like a fairly straightforward implementation. @runtime_checkable class SupportsString(Protocol): """An ABC with one abstract method __str__.""" __slots__ = () @abstractmethod def __str__(self) -> str: pass Perhaps there is another way to do this that I am missing?

5 8

CPP Namespaces For Python
by Alperen Keleş Oct. 8, 2020

Oct. 8, 2020

Hi, Please pardon me if my idea is not making sense or already exists, I'm kind of new to developing in Python but I had this idea today and I wanted to share it with you. I think a class type such as "@functionclass" may be helpful for creating functions intended to keep a list of methods in a scope. At the moment, I achieved this via writing "@classmethod" to all my functions but I think such a decorator might help clarify intent for the reader and ease the programmers' job. My regards, Alperen

10 17

Method to efficiently advance iterators for sequences that support random access
by Kevin Mills Oct. 7, 2020

Oct. 7, 2020

str_iterator, bytes_iterator, range_iterator, list_iterator, and tuple_iterator (and probably others) should have a method that is capable of efficiently advancing the iterator, instead of having to call next repeatedly. I suggest adding an itertools.advance function which dispatches to a dunder __advance__ method (if one exists) or, as a fallback, calls next repeatedly. Then, the iterators mentioned above (and any others capable of efficiently doing so) would implement __advance__, which would directly manipulate their index to efficiently "jump" the desired number of elements in constant-time rather than linear-time. For example, if you have a large list and want to iterate over it, but skip the first 50000 elements, you should be able to do something like: it = iter(mylist) itertools.advance(it, 50000) Note that you technically can do this with itertools.islice by supplying a start value, but itertools.islice effectively just repeatedly calls next on your behalf, so if you're skipping a lot of elements, it's unnecessarily slow. As a side note, I noticed that list_iterator has __setstate__ which can be used to (more or less) accomplish this, but that seems very hack-y. Although it is setting the index directly (rather than adding to it), so it'd be more awkward to use if the iterator is already partially exhausted. it = iter(mylist) it.__setstate__(50000)

13 28

Allow writing optional types as ?int
by Sebastian Noel Lübke Oct. 7, 2020

Oct. 7, 2020

Hey, python 3.9 introduced the | operator for union types. it would be nice to have something like that for optional types. maybe like name: ? int or name: int ? best regards Sebastian Lübke

4 4

PEP 637 - problems not solved by existing language
by Jonathan Fine Oct. 7, 2020

Oct. 7, 2020

SUMMARY This post asks for some examples that will improve PEP 637, by providing examples where the existing language specification is not adequate (but PEP 637 is). The rest of this post should tell you why I want these examples, and what they should look like. DISCLAIMER I'm an editor of PEP 637, writing in my personal capacity. And I'm also the author of package kwkey mentioned below. SUMMARY PEP 637 adds to Python's syntax and semantics. It adds statements such as >>> x[1, 2, a=3, b=4] = val to the syntax, and adds new associated semantics. https://www.python.org/dev/peps/pep-0637/ PEP 1, which defines the PEP process, states that any PEP that changes the existing language specification should clearly explain "why the existing language specification is inadequate to address the problem that the PEP solves". https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep As part of addressing this question of existing Python being adequate, I wrote a new package kwey. This package provides, I believe, a class B such that >>> B(1, 2, a=3, b=4)[x] = val is equivalent to >>> x[1, 2, a=3, b=4] = val once PEP 637 is implemented. (And if not, please report a bug, and if you can provide a patch.) https://pypi.org/project/kwkey/ GOAL The current version of PEP 637 doesn't mention kwkey. I'd particularly like us to look for problems where using kwkey as above is not adequate but PEP 637 is adequate. Aside. Please treat this as a semantic problem, or in other words assume that >>> x[SOMETHING] >>> f(SOMETHING) impose the same constraint on a well-formed expression SOMETHING. Here's why. PEP 637 allows syntax such as >>> x[1:2, 3:4, a=5:6, b=7:8] and even after PEP 637 (as it currently is) >>> f(1:2, 3:4, a=5:6, b=7:8) is forbidden syntax. But PEP 637 is much more than a syntax extension. Recall that we already have literal expressions such as >>> [1, 2, 3] # List literal >>> (1, 2, 3) # Tuple literal >>> {1, 2, 3} # Set literal in Python. If current Python turns out to have adequate semantics, then perhaps adding >>> (1:2:3) # Slice literal might by itself be enough. This is why I want particularly semantics examples. They're worth more. CONCLUSION I'd like to see semantic examples of problems that can be adequately solved by PEP 637, but not by using kwkey. The PEP process says, in so many words, that such examples should be provided. -- Jonathan

3 6

__call__ on lists, dicts etc.
by george.winton.harding＠gmail.com Oct. 5, 2020

Oct. 5, 2020

Hi all, I've been working in q and k, which is where this idea comes from. My idea is to make lists and dicts callable, with __call__ = __getitem__. So that: [3,4,5](1) gives 4 {'a':1, 'b': 2}('b') gives 2 Arguably a list is a function which maps from range(len(list)) to the list entries, and a dictionary is a function that maps from keys to values. This would mean that functions designed to take functions, can be repurposed to take data, for example: map(lst, idxs) instead of (lst[i] for i in idxs) or map(lambda x: lst[x], idxs) map(dct, lst) instead of (dct[l] for l in lst) sorted(range(len(lst)), key=lst) to calculate the equivalent of np.argsort max(range(len(lst)), key=lst) to calculate the equivalent of np.argmax I couldn't find this being discussed before. Does anyone like it? There is room for confusion as it would mean that e.g. filter([1,2], [0,1]) would give [0,1] whilst [1] might be expected. Best, George Harding p.s. Thank you to everyone for their work on such a wonderful language.

3 2

A new suggestion for Python
by Jonatan Oct. 3, 2020

Oct. 3, 2020

Hi, My name is Jonatan and i am programming in Python for about 4 years, I have a great idea, there are iX` methods, such as __ior__, __iadd__, __iand__ etc.., which implements the |=, +=, &= behavior, it would be nice if you could implement also __igetattr__ or something, which means: instead of con = "some text here" con = con.replace("here", "there") we could do con = "some text here" con .= replace("here", "there") Please let me know what do you think about it, Jonatan

12 16