Mailman 3 June 2020 - Python-ideas

New attribute __convert__ for classes
by artem6191 14 Jun '20

14 Jun '20

This attribute will use for convertion classes to other types, i.e. int(MyClass) will return __convert__ result in MyClass Example: class MyClass: def __init__(self, numer: int): self.number = number def __convert__(self, type): assert type == int # Only integer is allowed return self.number*5 # Example test = MyClass(1) test_2 = MyClass(5) print( int(test) ) # 5 print( int(test2) ) # 25

5 4

await outside async function could map to asyncio.run ?
by J. Pic 14 Jun '20

14 Jun '20

Hi all, Currently, you can not use await outside an async function, the following code: async def lol(): return 'bar' def test(): return await lol() print(test()) Will fail with: SyntaxError: 'await' outside async function Of course, you can use asyncio.run and then it works fine: import asyncio async def lol(): return 'bar' def test(): return asyncio.run(lol()) print(test()) Why not make using await do asyncio.run "behind the scenes" when called outside async function ? Thank you in advance for your replies -- ∞

6 10

await by default
by J. Pic 14 Jun '20

14 Jun '20

Hi all, Just wonder what it would look like if coroutines where awaited by default, you would only have to use "noawait" when you do *not* want to await a coroutine ? async def test(): return do_something() # it's awaited here by default: we get the result and not a coroutine result1 = test() # not awaiting here because you want to do_something_else coroutine = noawait test() do_something_else() result2 = await coroutine Then, you could be chaining code again like this: foo_of_result = test().foo Instead of: foo_of_result = (await test()).foo Thank you in advance for your replies Have a great weekend ! -- ∞

6 23

Postpone Python 4 for another 5 years
by João Bernardo 13 Jun '20

13 Jun '20

Now that double digits reached Python 3 and for the sake of maintaining compatibility for longer since Python 2.7 recently passed away and people is finally migrating after 12 years, I propose 5 new Python 3 versions: So we can have Python 3.10, 3.11, 3.12, 3.13 and finally 3.14 a.k.a Pi-thon Regards

4 3

[Python-Dev] Making asyncio more thread-friendly
by Stephen J. Turnbull 12 Jun '20

12 Jun '20

Hi, Celelibi, Welcome to Python Ideas. Python Dev is more for discussions of implementations of proposed features, typically clearly on their way to an accepted pull request into master. Python-Ideas is a better place for a request for enhancement without an implementation patch, so I'm moving it here. You're also more likely to get discussion here. Celelibi writes: > Hello world, > > I always knew asynchronous programming is awesome. And having a language > support for it really help its adoption by limiting the existence of > incompatible event frameworks which would be a pain to use together. > > However, the asynchronousness is very contaminating. Yes. I would expect that. > This makes it difficult to make threads and asyncio coexist in a > single application True. Do you know of a programming environment that makes it easy that we can study? > Unless I'm mistaken, there's no obvious way to have a function run a > coroutine in a given event loop, no matter if the loop in running or > not, no matter if it's running in the current context or not. > There are at least 3 cases that I can see: > 1) The loop isn't running -> run_until_complete is the solution. > 2) The loop is running in another context -> we might use > call_soon_threadsafe and wait for the result. > 3) The loop is running in the current context but we're not in a > coroutine -> there's currently not much we can do without some major > code change. > > What I'd like to propose is that run_until_complete handle all three > cases. I don't see how the three can be combined safely and generically. I can imagine approaches that might work in a specific application, but the general problem is going to be very hard. async programming is awesome, and may be far easier to get 100% right than threading in some applications, but it has its pitfall too, as Nathaniel Smith points out: https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-… > Did I miss an obvious way to make the migration from threads to asyncio > easier? Depends on what your threads are doing. If I were in that situation, I'd probably try to decouple the thread code from the async code by having the threads feed one or more queues into the async code base, and vice versa. > It becomes harder and harder to not believe that python is purposfully > trying to make this kind of migration more painful. Again, it would help a lot if you had an example of known working APIs we could implement, and/or more detail about your code's architecture to suggest workarounds. Regards, Steve

4 6

Make `del x` an expression evaluating to `x`
by Eric Wieser 12 Jun '20

12 Jun '20

TL;DR: should we make `del x` an expression that returns the value of `x`. ## Motivation I noticed yesterday that `itertools.combinations` has an optimization for when the returned tuple has no remaining ref-counts, and reuses it - namely, the following code: >>> for v in itertools.combinations([1, 2, 3], 1): ... print(id(v)) ... del v # without this, the optimization can't take place 2500926199840 2500926199840 2500926199840 will print the same id three times. However, when used as a list comprehension, the optimization can't step in, and I have no way of using the `del` keyword >>> [id(v) for v in itertools.combinations([1, 2, 3], 1)] [2500926200992, 2500926199072, 2500926200992] `itertools.combinations` is not the only place to make this optimization - parts of numpy use it too, allowing a = (b * c) + d to elide the temporary `b*c`. This elision can't happen with the spelling bc = b * c a = bc + d My suggestion would be to make `del x` an expression, with semantics "unbind the name `x`, and evaluate to its value". This would allow: >>> [id(del v) for v in itertools.combinations([1, 2, 3], 1)] [2500926200992, 2500926200992, 2500926200992] and bc = b * c a = (del bc) + d # in C++, this would be `std::move(bc) + d` ## Why a keyword Unbinding a name is not something that a user would expect a function to do. Functions operate on values, not names, so `move(bc)` would be surprising. ## Why `del` `del` already has "unbind this name" semantics, and allow it to be used as an expression would break no existing code. `move x` might be more understandable, but adding new keywords is expensive ## Optional extension For consistency, `x = (del foo.attr)` and `x = (del foo[i])` could also become legal expressions, and `__delete__`, `__delattr__`, and `__delitem__` would now have return values. Existing types would be free to continue to return `None`.

15 50

New syntax for dict literals
by Atsuo Ishimoto 11 Jun '20

11 Jun '20

Hello, It is sometimes tedious to write a dictionary in Python. For example, def register_user(first, last, addr1, addr2): d = {'first': first, 'last': last, 'addr1': addr1, 'addr2': addr2, 'tel': '123-456-789'} requests.post(URL, d) The dict literal contains a lot of duplicated words and quotation marks. Using dict type looks nicer, but still verbose. d = dict(first=first, last=last, addr1=addr1, addr2=addr2, tel='123-456-789') With recent JavaScript, the same object can be written more easily. d = {first, last, addr1, addr2, tel='123-456-789'} How about adding similar syntax to Python? Like raw strings, we can add prefix letters such as '$' to the opening curly brace for the purpose. d = ${first, last, addr1, addr2, tel='123-456-789'} Keys should be valid identifier strings. Other keys raise SyntaxError. I wrote a simple POC implementation here. It looks working. https://github.com/atsuoishimoto/cpython/pull/2 (I prefer to use `j` for the prefix over `$`, but I may need to study the parser more to use an ASCII letter as token.)

7 12

url imports
by Aditya Shankar 10 Jun '20

10 Jun '20

it'd be really cool if we could drop virtualenvs + requirements.txt altogether, i.e., like deno, mordern javascript and so... i.e. instead of `pip install package` and `import package` and `pip freeze > requirements.txt` for every import, we stick to, for every python script `abc = import("package", "2.*")` from imports could be done like `value = import("package", "1.*").value ` this completely removes the virtualenvs issue, and solves alot of problematic issues with python imports

4 3

JSON Serializing UUID objects
by J. Pic 10 Jun '20

10 Jun '20

Hi all, This is a proposal to enable uuid objects serialization / deserialization by the json module out of the box. UUID objects cast to string: >>> example = uuid.uuid4() >>> str(example) 'b8bcbfaa-d54f-4f33-9d7e-c91e38bb1b63' The can be casted from string: >>> example == uuid.UUID(str(example)) True But are not serializable out of the box: >>> json.dumps(example) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.8/json/__init__.py", line 231, in dumps return _default_encoder.encode(obj) File "/usr/lib/python3.8/json/encoder.py", line 199, in encode chunks = self.iterencode(o, _one_shot=True) File "/usr/lib/python3.8/json/encoder.py", line 257, in iterencode return _iterencode(o, 0) File "/usr/lib/python3.8/json/encoder.py", line 179, in default raise TypeError(f'Object of type {o.__class__.__name__} ' TypeError: Object of type UUID is not JSON serializable Wouldn't it be pythonically possible to make this work out of the box, without going through the string typecasting ? If that discussion goes well perhaps we can also talk about datetimes ... I know there's nothing about datetime formats in the json specification, that users are free to choose, but could we choose a standard format by default that would just work for people who don't care about the format they want. Thank you in advance for your replies Have a great day -- ∞

8 18

Re: PYTHONLOGGING env variable
by Steven D'Aprano 10 Jun '20

10 Jun '20

On Sat, Jun 06, 2020 at 09:31:36PM +0300, Bar Harel wrote: > > > > It's one thing to say that the interpreter takes care of importing > > logging and setting up a basic logger, and that's great, but I still > > have to import logging and call the `logging.info(...)` functions, > > so what does this proposal give us, *in detail* please, and how do I use > > it? > > > > You would be able to easily see the logs already generated by libraries, > without needing to ever modify the Python files. But if the libraries are already doing logging, can't I already do that? And if the libraries aren't doing logging, this won't magically add logging to them, will it? I think I need to see a (simplified!) but practical example of how this would work, from both the point of view of the library creator, and the library user. Thanks, -- Steven

2 1