Mailman 3 August 2020 - Python-ideas

Add methods to perform path validation to pathlib.Path
by Charles Machalow Aug. 12, 2020

Aug. 12, 2020

I was reading https://stackoverflow.com/questions/7406102/create-sane-safe-filename-from-… and was thinking that functionality to create safe paths from unsafe paths and check if a Path would work on a given filesystem would well in Pathlib.

2 1

PEP 472 -- Support for indexing with keyword arguments
by Andras Tantos Aug. 11, 2020

Aug. 11, 2020

Hello! I'm not sure I'm addressing the right audience here, so please direct me to the appropriate channel if that's the case... My name is Andras Tantos and I'm working on a Python library desscribing HW designs. I came across this problem of __getitem__ and co. not supporting kwargs. Apparently this extension was proposed and rejected as PEP 472. Apart from my use-case, which is arguably a corner-case and not worth modifying the language for, I believe there are two important use-cases that are worth considering with the latest improvements in the language: 1. With the recent type-hint support, the feature could be made way more descriptive if this PEP got implemented. For example, instead of doing the following: def func(in: Dict[str, int]) one could write: def func(in: Dict[key=str, value=int]) 2. It would also make 'generic classes' much cleaner to implement, similar to the way type-hints look. Consider the following code: class_Generic(object): Specializations = [] @classmethod def__getitem__(cls, *args): name = f"Generic_{len(cls.Specializations)}" Specialized = type(name, (cls,), {"specials": tuple(args)}) cls.Specializations.append(Specialized) returnSpecialized def__init__(self, value= None): self.value = value def__str__(self): ifhasattr(self, "specials"): return(f"[{type(self)}- "+ ",".join(str(special) forspecial inself.specials) + f"] - {self.value}") else: return(f"[{type(self)}- GENERIC"+ f"] - {self.value}") Generic = _Generic() #g = Generic() - fails because of no specialization is given s1 = Generic[12]() s2 = Generic[42]("Hi!") print(s1) print(s2) Running this simple example results in: python3 -i python_test.py [<class '__main__.Generic_0'> - 12] - None [<class '__main__.Generic_1'> - 42] - Hi! You can see how the specialized parameters got passed as well as the ones to '__init__'. Obviously, in real code the idea would be to filter generic parameters and set up 'Specialized' with the right set of methods and arguments. Now, without kwargs support for __getitem__, it's impossible to pass named arguments to the specialization list, which greatly limits the usability of this notation. I don't know how convincing these arguments and use-cases are for you, but could you advise me about how to start the 'ball rolling' to drum-up support for re-activating this PEP? Thanks again, Andras Tantos

24 74

Universal set
by haael Aug. 10, 2020

Aug. 10, 2020

Forgive me if this has already been discussed. Could we add the idea of "negative" sets to Python? That means sets that contain EVERYTHING EXCEPT certain elements. First, let's have a universal set that contains everything. assert element in set.UNIVERSAL The universal set is a superset of every other set. assert set.UNIVERSAL >= any_set Adding anything to universal set doesn't change anything. assert set.UNIVERSAL | element == set.UNIVERSAL However REMOVING an element from the set puts it on "negative list". myset = set.UNIVERSAL myset.remove(element) assert element not in myset Intersection of a "negative set" with a normal set gives again a normal set. Union of two negative sets, or a negative set with a normal set, gives a negative set. The main issue: negative sets would not be iterable, but you can intersect them with the desired subdomain and iterate over.

8 7

use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`
by Ricky Teachey Aug. 9, 2020

Aug. 9, 2020

This was inspired by a tweet today from Brandon Rhodes. I looked for something like it on the mypy issues page and didn't find anything. Would it make good semantic sense- and be useful- to specify valid numerical ranges using slices and type-hint syntax? My suggestion would be to, at minimum, provide this functionality for int and float. Consider that currently we have: x: int # this means "all ints", today x: float # this means "all floating point numbers", today Idea in a nutshell would be for the following type declarations to mean: x: int[0:] # any ints greater than or equal to zero would match, others would fail x: int[:101] # any ints less than 101 match x: int[0:101:2] # even less than 101 # for floats, it's a bit odd since the upper bound is typically exclusive... # but we might prefer it to be inclusive? Not sure. # regardless, any float within the range matches import math x: float[-math.pi:math.pi] # any angle in radians from -pi to pi x: float[-180:180] # any angle in degrees from -180 to 180 So going with the angle example, one use-case might be something like: """my_module.py""" import math def atan_deg_int(v: float) -> int[-90:91]: """Computes the angle in integer degrees using arctangent.""" return math.atan(v) * 180/math.pi if __name__=="__main__": AngleDeg = float[0:360] # a positive angle up to 360 degrees x: AngleDeg x = atan_deg_int(-0.5) Then we would get an error similar to below: >>> mypy my_module.py <string>:1: error: Incompatible types in assignment (expression has type "int[-90:91]", variable has type "float[0:45]") Here the error occurs not because ints are considered inconsistent with floats (mypy allows ints in the place of floats, so no problem there), but because some of the ints from -90 to 90 (inclusive) fall out of the float range of 0 to 360. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

9 20

Inline Try-Except Clause
by Jonathan Grant Aug. 9, 2020

Aug. 9, 2020

Hey all, Instead of writing this: ``` try: return my_dict[“a”][“b”][“c”][“d”] except: return “some default” ``` Or this ``` return my_dict.get(“a”, {}).get(“b”, {}),get(“c”, {}).get(“d”, “some default”) ``` I propose we allow for an inline exception handler, like `eor`: ``` return my_dict[“a”][“b”][“c”][“d”] eor “some default” ``` This works very similar to what we already have with `or`, and makes code much more compact and readable. -- Cheers, Jonathan

15 33

`property.apply` decorator
by Roger Serwy Aug. 8, 2020

Aug. 8, 2020

The property decorator, with its .setter and .deleter chaining, is a bit cumbersome and repetitive. If we can add `.apply` as a method on property that calls a function that returns the fget/fset/fdel/doc arguments, it would simplify instantiating the descriptor. For example: @property.apply def attr(): def fget(self): pass def fset(self, value): pass def fdel(self): pass return (fget, fset, fdel, "doc") instead of @property def attr(self): pass @attr.setter def attr(self, value): pass @attr.deleter def attr(self): pass An example implementation using `fproperty` exists at https://github.com/serwy/fproperty

2 2

Function suggestion: itertools.one()
by Noam Yorav-Raphael Aug. 8, 2020

Aug. 8, 2020

Hello, There's a simple function that I use many times, and I think may be a good fit to be added to itertools. A function that gets an iterator, and if it has exactly one element returns it, and otherwise raises an exception. This is very useful for cases where I do some sort of query that I expect to get exactly one result, and I want an exception to be raised if I'm wrong. For example: jack = one(p for p in people if p.id == '1234') sqlalchemy already has such a function for queries: https://docs.sqlalchemy.org/en/13/orm/query.html#sqlalchemy.orm.query.Query… more-itertools has this exact function: https://more-itertools.readthedocs.io/en/latest/api.html#more_itertools.one Here is a simple implementation: def one(iterable): it = iter(iterable) try: first = next(it) except StopIteration: raise ValueError("Iterator is empty") try: second = next(it) except StopIteration: return first else: raise ValueError("Iterator has more than one item") I brought this up on python-dev, but it should be discussed here. Here is the discussion: https://mail.python.org/archives/list/python-dev@python.org/thread/D52MPKLI… Brett Cannon said that this idea has been brought up at least twice before. I found: https://mail.python.org/archives/list/python-ideas@python.org/thread/FTJ6JR… https://mail.python.org/archives/list/python-ideas@python.org/thread/REYDJF… The first thread hasn't reached any operative conclusion. The second thread was very long, and seemed to focus mostly on another function, first(), that doesn't check if there is more than one item. Joao S. O Bueno said that it passed "general approval". I think that perhaps a new discussion, focused just on one (no pun intended) function in the itertools module may reach a conclusion. It was suggested that instead of an additional function, one can use iterator unpacking: jack, = (p for p in people if p.id == '1234') or [jack] = (p for p in people if p.id == '1234') I still think that having a one() function would be useful, since: 1. I think it spells the intention more clearly. It is not symbols that you need to understand their meaning in order to understand that I expect the iterable to have exactly one item, it's spelled in code. 2. The exception would be easier to understand, since errors in tuple unpacking usually mean something else. 3. The one() function allows you to use the result inside an expression without assigning it to a variable. Therefore, I think it encourages writing better code. It's very easy to write: print([p for p in people if p.id == '1234][0]) (which has the problem of not verifying the assumption that there's no more than one result), and I find it easier to replace _[0] with one(_) than to be required to name a new variable, and instead of having an operation on the iterable, change the way I'm assigning to it. WDYT? Cheers, Noam

4 4

bpo-41231: wraps default behavior with __annotations__
by David Caro Aug. 8, 2020

Aug. 8, 2020

Hi! Some time ago I opened a bug and sent a patch, but I realize that I should have started a chat here first, better late than never. The default behavior of the `functools.wraps` decorator, is to copy over the `__annotations__` from the wrapped function to the wrapper function. This is ok if the wrapper function has the same signature that the wrapped one (that I guess was the main goal behind it, just a simple wrapper). The issue comes when the wrapper function has a different signature than the wrapped, for example, the `contextlib.contextmanager` decorator, changes the return value, returning a `_GeneratorContextManager`: ``` def contextmanager(func): """... """ @wraps(func) def helper(*args, **kwds): return _GeneratorContextManager(func, args, kwds) return helper ``` but as it uses `wraps`, the `__annotations__` will be copied over, and the new function will have an incorrect return type there. In order to improve this, I have some proposals: 1. Keep the default behavior of `wraps`, but change the usage around the library to not copy over the `__annotations__` in places (like `contextmanager`) where the types change. Advantages are that `wraps` keeps being backwards compatible, though the change in `contextmanager` might force some people to "fix" their annotations, I would consider that a "bugfix", more than a behavior change. The disadvantage is that you have to know that `wraps` will overwrite the wrapped function annotations by default, and I think that it's broadly used when creating decorators that have different signature/types than the wrapped function, so people will have to explicitly change their code. 2. Change `wraps` so if there's any type of annotation in the wrapper function, will not overwrite it. This is what I did in the PR (though I'm not convinced). Advantages are that only people that took the time to annotate the wrapper function will see the change, and that will be the change they expect (that's my guess though). It's a bit smart with it, so if you don't specify a return type, will get it from the wrapped function, or if you don't specify types for the arguments will get them from the wrapped function, filling only the gap that was not specified. For everyone else, `wraps` is backwards compatible. Disadvantages, it's a bit more convoluted as it requires some logic to detect what annotations are defined in the wrapper and which ones in the wrapped and merge them. 3. Change the default behavior of `wraps` and don't overwrite the `__annotations__` property. This is non-backwards compatible, but imo the simplest. Advantages are that it's very simple, and you'll end up with valid, straight-forward `__annotations__` in the wrapped function (that is, whatever you declare when writing the wrapped function). Disadvantages, if the goal of the `wraps` decorator was as a helper when wrapping functions in a simple manner (not changing the signature), then this becomes a bit more inconvenient, as it will not copy the `__annotations__` as it was doing by default. It also changes the current default behavior, so it will potentially affect everyone that uses `wraps` currently. Ideas? Thanks! -- David Caro

2 2

Package kwkey and PEP 472 -- Support for indexing with keyword arguments
by Jonathan Fine Aug. 8, 2020

Aug. 8, 2020

SUMMARY: Some news. I've just published https://pypi.org/project/kwkey/0.0.1/. This package is about PEP 472 -- Support for indexing with keyword arguments See: https://www.python.org/dev/peps/pep-0472/ As a result, I think we're now in a good position to try this idea out, using present day Python. This includes building some clients that can use the new feature, should it become available. It also includes exploring the design of the API. The crucial idea is writing >>> from kwkeys import o >>> d[o(1, 2, a=3, b=4)] as a stopgap, until >>> d[1, 2, a=3, b=4] is available. If you're interested, please do try it out. IN MORE DETAIL: On 3 May 2020, Andras Tontas reopened discussion of the PEP. This PEP was created in June 2014, and closed in March 2019, due to lack of interest. See: https://mail.python.org/pipermail/python-dev/2019-March/156693.html This time round, things went better. On 16 July, Guido wrote (substitute PEP for PRP) I think it’s a reasonable idea and encourage you to start working on a > design for the API and then a PRP. It would help if someone looked into a > prototype implementation as well (once a design has been settled on). See: https://mail.python.org/archives/list/python-ideas@python.org/message/7MHQY… Later on 16 July, I wrote > I'll now state some goals. > > 1. Define 'o' and Protocol so that NOW gives the semantics you wish for. > 2. Extend Python so that FUTURE give the semantics you wish for. > 3. And the NOW syntax continues to work as expected (without changing 'o' > and Protocol). > 4. And all current use of container[key] continues to work as before. > > I believe that it is possible to achieve these goals. My previous posts to > this discussion outline some of the key ideas. My next step, when I have > time, is to implement and publish general purpose code for the NOW part of > this list of goals. See: https://mail.python.org/archives/list/python-ideas@python.org/message/3IWL4… On 18 July I wrote that by the end of July I would implement and publish general purpose code for the NOW part of these goals See: https://mail.python.org/archives/list/python-ideas@python.org/message/YW3JX… Earlier today, 3 days overdue, I fulfilled my commitment. I hope it helps some of you, and does no harm to others. -- Jonathan

12 35

Propouse add context to json module.
by Kazantcev Andrey Aug. 7, 2020

Aug. 7, 2020

JSON serialization used in many different libraries without the ability for configuration (Example https://github.com/aio-libs/aioredis/blob/8a207609b7f8a33e74c7c8130d97186e7…). Propose to add something like the context in the decimal module, wIch will contain all global configs for dump and load functions. Thanks!

7 13