Mailman 3 July 2020 - Python-ideas

multidimensional lists
by Hans Ginzel 08 Jul '20

08 Jul '20

Why not to allow tuple as a list index? >>> T = [[11, 12, 5, 2], [15, 6, 10], [10, 8, 12, 5], [12, 15, 8, 6]] >>> print(T[1][2]) 10 >>> print(T[1, 2]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: list indices must be integers or slices, not tuple https://stackoverflow.com/questions/40361743/python-using-tuples-as-list-in…

3 3

functools.partial not freezing the keyword arguments
by ndg1＠eurimail.com 07 Jul '20

07 Jul '20

The official doc of the partial function from the functools stdlib module says it "is used for partial function application which “freezes” some portion of a function’s arguments and/or keywords resulting in a new object with a simplified signature". However, whereas positional arguments are effectively "frozen" (cannot be altered in the partial object), keyword arguments can in fact not be frozen as they always will be overridden by the ones passed to the partial object. The "and/or keywords" part in the quote above thus sounds wrong when applied to the current implementation, and is more accurately describing the following situation : def partial(func, /, *args, **keywords): def newfunc(*fargs, **fkeywords): return func(*args, *fargs, **keywords, **fkeywords) # instead of the current func(*args, *fargs, **{**keywords, **fkeywords}) value newfunc.func = func newfunc.args = args newfunc.keywords = keywords return newfunc Shouldn't we provide the above implementation - which really freezes the given positional AND keyword arguments - in a new partial function to be added to the functools module, and fix the docs accordingly ? On the signature side, we would also actually always get a "new object with a simplified signature" as stated in the doc, which is not the case currently. If we consider the following code : import functools def F(arg, opt = 'BaseValue') : return (arg, opt) G = functools.partial(F, opt = 'NewValue') the partial function G's signature is (arg, opt = 'NewValue') and is not really simplified compared to the initial (arg, opt = 'BaseValue') one. The only effect of partial on the function signature is to alter the default values of the specified keyword arguments. With the proposed implementation, the signature would actually be simplified to (arg).

1 0

Re: giving set.add a return value
by Christopher Barker 07 Jul '20

07 Jul '20

Sorry, this got lost in the shuffle without being sent, and the conversation seems to have died down. but since I wrote it ... On Sat, Jul 4, 2020 at 8:25 AM Stephen J. Turnbull < turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > Christopher Barker writes: > > > I am really confused here -- I'm suggesting that is should NOT be > possible > > to tell the difference. > > But it is possible to tell the difference, so that suggestion is moot. I meant in the context of putting things in, or testing whether they are in, sets. Not in any other context. There are languages where there is no numeric tower, just numbers, and > [0][0], [0][0.0], and [0][0+0j] all just work. Python isn't one of > them. Fewer places you can tell in Python 3 than in Python 2, I > believe, but several remain. Sure, but putting them in sets, or using them as a key in a dict is not one of them. set.intern does yield the same result regardless of what's passed in: > whichever is in the set. That's *why* I can call it "intern".[1] Fair enough. You can of course propose any functionality you want. I’m suggesting that my understanding of what you are proposing doesn’t match well with the rest of how sets work. But to see if I understand correctly, you couldn’t quite use a set to intern objects: once 2.0 was in there you could not put 2 in as well. You could know that 2.0 was already in there when you tried to add 2, but it would still never be added. It seems if you really want to intern objects, you’d need something kind of like, but not quite, a set(). Note: this all is only an issue for object that are of a different type, but can compare equal and have the same hash - maybe the numeric types are the only ones in the stdlib for which this is the case. Nevertheless, they are commonly used :-) Nope: turns out NamedTuples and Tuple are the "same" as far as sets are concerned as well. In [66]: s = {p} In [67]: s Out[67]: {Point(x=2, y=3)} In [68]: s.add((2,3)) In [69]: s Out[69]: {Point(x=2, y=3)} In [70]: s = {(2,3)} In [71]: s.add(p) In [72]: s Out[72]: {(2, 3)} So if you want something that treats different types with the same value as different, you really will need a different storage mechanism than a set. -CHB

3 2

Re: Best approach for opaque PyObject
by William Pickard 06 Jul '20

06 Jul '20

CPython PR #21262, GitHub username is Wildcard65.

2 11

Re: Add builtin function for min(max())
by Federico Salerno 06 Jul '20

06 Jul '20

On the topic of NaNs: I think in the face of ambiguity, we should refuse the temptation to guess and raise ValueError when the values given are not comparable to the point of clearly determining whether `value` is or isn't within `minimum` and `maximum` or which of the two bounds it exceeds. It is the programmer's responsibility to ensure they supply arguments that make sense, and non-numbers should be considered exceptional behaviour: as such, the programmer that anticipates those kinds of values should handle them exceptionally. About the name: clamp seems to be the most favoured name and the discussion convinced me it's the one that should make it to the eventual proposal. About the stdlib/builtin status: `min(max(x, min_), max_)` is a common enough idiom for a simple enough function that I think it is definitely beneficial and in no way dangerous to have, and that any status other than builtin would incur too much overhead for something so small. I risk claiming that most calls to max() and min() occur in modules that do not `import math` (or at the very least, they occur often enough without `import math`), and I believe clamp(), being very similar in scope to those, should benefit from similar status. I don't think clamp is a common enough identifier in non-specific fields to disqualify its implementation as a builtin by itself. By contrast, terms like `min` and `max` are extremely common in pretty much all contexts, and yet we've all survived just fine by typing `min_` and `max_` or even shadowing the names altogether (which I prefer not to do, but is definitely an option). FInally, I'd like to lit another fire: given that `min()` and `max()` accept an arbitrary amount of arguments, and that the signature that seems to be preferred for the hypothetical clamp at the moment sees `value` as the first positional argument, should the function then accept iterables as values for `minimum` and `maximum`? Something along the lines of: clamp(value: Number, minimum: Union[Number, Iterable[Number]], maximum: Union[Number, Iterable[Number]])

5 8

exception instance call should raise exception
by Soni L. 05 Jul '20

05 Jul '20

ValueError()() should be the same as raise ValueError() but with an extra call level. and raise should be deprecated.

4 8

Else assert statement
by Artemis 05 Jul '20

05 Jul '20

Often, I know that a variable should have one of a set of values, and I want to determine which one, with an if/elif/else clause. This looks something like this: ``` if foo == 1: # do a elif foo == 2: # do b elif foo == 3: # do c else: raise ValueError('foo must be 1, 2 or 3') ``` Sometimes, I just do ``` if foo == 1: # do a elif foo == 2: # do b else: # do c ``` But this is less readable and allows errors to slip past. My proposal is to allow the following syntax: ``` if foo == 1: # do a elif foo == 2: # do b else foo == 3: # do c ``` Or perhaps the more readable version: ``` if foo == 1: # do a elif foo == 2: # do b else assert foo == 3: # do c ``` Both of these options are backward compatible, since currently nothing is allowed between the `else` and the `:`. This would be roughly equivalent to ``` if foo == 1: # do a elif foo == 2: # do b else: assert foo == 3 # do c ``` But shorter and more readable, since it puts the assertion at the same levels as the others. Thoughts?

5 6

An alternative way of defining properties (warning: contains creative abuse of the class statement)
by Greg Ewing 03 Jul '20

03 Jul '20

The @property.getter and @property.setter decorators are clever, but they have the disadvantage that you end up writing the name of the property no less than 5 times, all of which have to match. Thinking there must be a better way, I came up with this: def Property(name, bases, dict): return property(dict.get('get'), dict.get('set')) which allows you to write class Test: class foo(metaclass = Property): def get(self): print("Getting foo") return self._foo def set(self, x): print("Setting foo to", x) self._foo = x test = Test() test.foo = 42 print(test.foo) Output: Setting foo to 42 Getting foo 42 -- Greg

8 21

giving set.add a return value
by Ben Avrahami 03 Jul '20

03 Jul '20

Hey all, Often I've found this kind of code: seen = set() for i in iterable: if i in seen: ... # do something in case of duplicates else: seen.add(i) ... # do something in case of first visit This kind of code appears whenever one needs to check for duplicates in case of a user-submitted iterable, or when we loop over a recursive iteration that may involve cycles (graph search or the like). This code could be improved if one could ensure an item is in the set, and get whether it was there before in one operation. This may seem overly specific, but dicts do do this: seen = {} for i in iterable: if seen.set_default(i, some_value) is not None: ... # do something in case of duplicates else: ... # do something in case of first visit I think the set type would benefit greatly from its add method having a return value. set.add would return True if the item was already in the set prior to insertion, and False otherwise. Looking at the Cpython code, the set_add_entry already detects existing entries, adding a return value would require no additional complexity. Any thoughts?

13 31

Re: Best approach for opaque PyObject
by William Pickard 03 Jul '20

03 Jul '20

I do have a plan to solve that problem, it involves adding about 24 more bytes to PyTypeObject, but it would allow Python to track offset from base object, total object size and best alignment value.

2 1

Python-ideas July 2020