Mailman 3 August 2021 - Python-ideas

startswith() and endswith() methods returning the matched value
by fgallaire＠gmail.com 10 Aug '21

10 Aug '21

This is a proposal to change the behaviour of the startswith() and endswith() methods for str, bytes and bytearray objects, making them return the matched value instead of the True boolean. Here a str example with the endswith() method: domain = "python.org" if domain.endswith(".fr"): print(".fr") elif domain.endswith(".com"): print(".com") elif domain.endswith("org"): print(".org") With the ".org" non-empty str returned by the endswith() method instead of the True boolean, the above code will work in the same manner; moreover as startswith() and endswith() methods support a tuple as argument, and as the PEP 572 walrus operator is supported since Python 3.8, we can now write this code in a more compact and pythonic way: if suffix := domain.endswith((".fr", ".com", ".org"): print(suffix) As the PEP 616 new methods removeprefix() and removesuffix() don't support a tuple as argument, it will provide a nice and pythonic way to do it: if suffix := domain.endswith((".fr", ".com", ".org"): print(domain[:-len(suffix)]) Hope I don't miss something obvious and that this proposal could interest some people. Best regards Florent

6 12

Proposal: Python Native bindings for OpenAPI
by Vaideeswaran Ganesan 09 Aug '21

09 Aug '21

OpenAPI (https://spec.openapis.org/oas/latest.html) is an emerging standard for defining RESTful interfaces. OpenAPI is supported by swagger - which provides tools to convert an OpenAPI spec into python code (for both backend as well as client). The proposition I have is to make OpenAPI native to python. Essentially, this involves some of the following: 1. OpenAPI provides definitions of objects, arrays, structures, primitive types, collections etc. 2. OpenAPI supports object creation (HTTPS POST), object modification (PUT), object deletion (DELETE) and object retrieval (GET). 3. OpenAPI also supports operations for collections (add to collection, remove from collection and modify collection) 4. OpenAPI also supports methods and allows parameters to be passed to these APIs. The Native Python implementation would load in OpenAPI specification and provide native Python experience as follows: 1. Primitive types are mapped to python primitive types 2. Objects and structures are treated as classes or dicts wrapped. The field names in the Spec are accessible. 3. Arrays and Collections are mapped to python lists. 4. URLs are converted into object structure. 5. Python inspection methods (__getattr__, __setattr__, __new__, __del__ and others) of this model is changed to manipulate the fetched objects dynamically Parts of this implementations are found in various places : sushy (OpenStack) etc. However, having a more organized approach would make life easier. Swagger has a tool that can generate the code. But this means that every time a specification changes you need to ship a new python library. The methodology presented not require any addition python libraries - the tool can download from the REST end point. By making OpenAPI native to python, we would avoid cumbersome handling of request codes etc. and make it as you we are accessing native objects. I can provide more details and a reference implementation I am working on. Wanted to know if this is worthy to be submitted as PEP!

4 7

Argparse.add_argument() argument for additional functionallity
by Hasan Aliyev 09 Aug '21

09 Aug '21

Hi. I would like to suggest to add functionality to argparse For example we can have one ArgumentParser instance, for (windows, linux), (community edition, pro edition) apps. It could give ability to show and be able to run only allowed commands based on version of os, app or some other logic. import argparse def some_callable(): if edition() == 'pro_edition': return True return False parser = argparse.ArgumentParser( prog="CustomProgramm", description="CustomProgramms custom description", epilog='Epilog of this', ) parser.add_argument('--full-function', target=some_callable) This --full-function argument will be available only if some_callable function is True, otherwise it will not be shown in command line arguments.

2 1

`not not x` much faster than `bool(x)`
by wyz23x2＠163.com 06 Aug '21

06 Aug '21

Before the introduction of bool and also in other languages, `not not x` was/is used to convert to True (1) and False (0). However, the old way is still much faster than bool(x) or even operator.truth(x). Test: > py -3.10 -m timeit -s "objects = 1, 0, -0.0, "20", "False", 93, 28.569, [], set(), {1: 5}" "[(not not x) for x in objects]" 200000 loops, best of 5: 1.12 usec per loop > py -3.10 -m timeit -s "objects = 1, 0, -0.0, "20", "False", 93, 28.569, [], set(), {1: 5}" "[(bool(x)) for x in objects]" 200000 loops, best of 5: 2.32 usec per loop > py -3.10 -m timeit -s "from operator import truth; objects = 1, 0, -0.0, "20", "False", 93, 28.569, [], set(), {1: 5}" "[(truth(x)) for x in objects]" 200000 loops, best of 5: 2.04 usec per loop > py -3.10 -V Python 3.10.0rc1 That's nearly 52%/46% faster! I guess the name lookup and the FUNCTION_CALL is slower than UNARY_NOT. So actually, using `not not` is an optimize, although it isn't clear. This is interesting.

5 5

More natural type hints for built-in containers
by Ignacio Pickering 02 Aug '21

02 Aug '21

Currently type hints for built-in containers are, in my opinion, less succint than required. I suspect it is probably not very difficult for a type checker to interpret something like this for example: var1: {str: (int, int)} = {"label": (1, 2)} var2: {str} = {"other_label"} def function(param1: {int: str} = {1: "foo"}, param2: (int, ...) = (1, 2, 3)) -> (int, (str, ...)): return 3, ("foo", "bar") as equivalent to: var1: dict[str, tuple[int, int]] = {"label": (1, 2)} var2: set[str] = {"other_label"} def function(param1: dict[int, str] = (1, "foo"), param2: tuple[int, ...] = (1, 2, 3)) -> tuple[int, tuple[str, ...]]: return 3, ("foo", "bar") I thought of posting something like this as a mypy feature suggestion, but I suspect the language would need to modify the way type annotations are interpreted for something like it to work (or maybe not?). Basically, inside a type annotation, the objects created by (a, b), [a], {a: b}, {a} would be reinterpreted as the same thing as constructing tuple[a, b], dict[a, b], list[a], set[a]. I have found myself wanting to write things like this a couple of times, so I think this overloaded usage of builtin containters is natural. I actually feel it is so natural it must either have been proposed before (in which case I would love to give the feature my +1) or there is some more or less obvious flaw.

5 6

Possibility to specify port in __init__ of ftplib.FTP
by Marty 01 Aug '21

01 Aug '21

Hi. If there is possible to connect and login to ftp server within __init__, I think it would make sense to add parameter **port** in ftplib.FTP. It could look like this: ``` def __init__(self, host='', port=0, user='', passwd='', acct='', timeout=_GLOBAL_DEFAULT_TIMEOUT, source_address=None, *, encoding='utf-8'): self.encoding = encoding self.source_address = source_address self.timeout = timeout if host: self.connect(host, port) if user: self.login(user, passwd, acct) ``` (Or port parameter could be added at the end of the __init__ parameters not to break current logic.) Currently if I need to specify port, I have to do it like this: ``` with FTP() as ftp: ftp.connect(host, port) ftp.login(user, password) # my actions ``` If the port parameter would be added, I could use it like this: ``` with FTP(host, port, user, password) as ftp: # my actions ``` In all my cases, all I need is to connect to ftp server and work with it. If there is some trouble with connection or login, the code still can't continue working with ftp... Do you rather use connect() and login() explicitly or just let it connect and login within __init__ implicitly? What do you think about it? Thanks.

2 1