[Python-ideas] Re: Unpack operator "**" and Mapping

On Mon, Dec 28, 2020 at 12:33 PM Guido van Rossum wrote: > On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker > wrote: > >> Though frankly, I would rather have had it use .items() -- seems more >> efficient to me, and you do need both the keys and the values, and items() >> is just as much

[Python-ideas] Re: built in to clear terminal

Mike Miller writes: > No offense, but if you're a developer who can't handle hotkeys or > came of age before the "glass tty" and won't learn any new tricks… > well, that's just *"your problem, mayan."* > > The rest of us are capable. :D The thing is, this is a destructive capability. In

[Python-ideas] Re: Add aggregations and joins code-generating library along with itertools

Dear Guido, I see! At least "isn't mature enough" doesn't sound like "doesn't fit at all" :) An of course there's a lot of room for improvements. Thank you and happy holidays! Nikita A On Mon, 2020-12-28 at 09:42 -0800, Guido van Rossum wrote: > Dear Nikita, > > I'm sorry to squash your idea,

[Python-ideas] Re: str.isfloat()

Alright, I see why `str.isfloat()` isn't a thing, and having a builtin float validation function was besides the point anyway. Thanks for the clarifications :) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Unpack operator "**" and Mapping

2020-12-28 Christopher Barker dixit: > I don't know about the OP, but all I wanted was a clear definition of > the part of the API needed to support **, and apparently it's a > keys() method that returns an iterator of the keys, and a __getitem__ [...] To be more precise: an *iterable* of the

[Python-ideas] Re: asyncio.Pipe()

I created an implementation on PyPI here: https://pypi.org/project/asyncio-pipe/ I am using the same function signatures that multiprocessing.Connection does. I use composition, and have changed recv(), poll, recv_bytes(), and recv_bytes_into(buffer) so that they will not block the event loop.

[Python-ideas] Re: A PEP to encourage people to mind docstrings in stub files

Endorsing putting docstrings in stub files is an intriguing idea, but I can see some potential issues with the approach: >From pep 484, the use-cases listed for stub files are: - Extension modules - Third-party modules whose authors have not yet added type hints - Standard library

[Python-ideas] Re: Unpack operator "**" and Mapping

On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker wrote: > > I don't know about the OP, but all I wanted was a clear definition of the > part of the API needed to support **, and apparently it's a keys() method > that returns an iterator of the keys, and a __getitem__ that then returns > the

[Python-ideas] Re: Unpack operator "**" and Mapping

On Mon, Dec 28, 2020 at 3:54 AM Steven D'Aprano wrote: > > Steven D'Aprano wrote: > > > Why do you want something that isn't a mapping to be usable with > mapping > > > unpacking? > > > > I think mapping is not `abc.Mapping` class only. > > You don't have to inherit from Mapping for this to

[Python-ideas] Re: built in to clear terminal

On 2020-12-26 19:45, 2qdxy4rzwzuui...@potatochowder.com wrote: On 2020-12-27 at 13:24:34 +1100, Steven D'Aprano wrote: But the ctrl-L trick has no discoverability. It took me close to twenty years of using Linux before I discovered it, and I still don't remember to use it when I need it.

[Python-ideas] Re: asyncio.Pipe()

Okay, fair. I am guessing that the first step would be to create a quality implementation and publish it on PyPI. And of course this begs the question, *who* is going to do the work? [ducks] On Mon, Dec 28, 2020 at 10:27 AM Roger Iyengar wrote: > It was not sufficient. The only way to

[Python-ideas] Re: asyncio.Pipe()

It was not sufficient. The only way to communicate with a Subprocesses is using stdout, stdin and stderr. However, packages like Tensroflow will print messages to stdout, and this can be hard to turn off. It seems useful to have a class like multiprocessing.Pipe to communicate with another

[Python-ideas] Re: asyncio.Pipe()

The asyncio module already has a subprocess support: Subprocesses — Python 3.9.1 documentation Was that not sufficient to solve your problem? On Mon, Dec 28, 2020 at 5:23 AM Roger Iyengar wrote: > I believe that asyncio should have a

[Python-ideas] Re: Add aggregations and joins code-generating library along with itertools

Dear Nikita, I'm sorry to squash your idea, but I don't think your library is mature enough to be considered for inclusion in the standard library. May 2021 be an improvement upon 2020, --Guido On Sun, Dec 27, 2020 at 7:04 AM Nikita Almakov wrote: > Hello everyone! > > The idea: it would be

[Python-ideas] Re: Add aggregations and joins code-generating library along with itertools

Hi Anton, Thank you very much for the time spent on this and the feedback! My answers are below: 1. I'm not sure whether the idea gains any traction to become a proposal (https://mail.python.org/mailman3/lists/python-ideas.python.org/ ) If an idea gains traction it can then be discussed and

[Python-ideas] asyncio.Pipe()

I believe that asyncio should have a way to wait for input from a different process without blocking the event loop. The Asyncio module currently contains a Queue class that allows communication between multiple coroutines running on the same event loop. However, this module is not threadsafe or

[Python-ideas] Re: Unpack operator "**" and Mapping

On Mon, Dec 28, 2020 at 08:44:07AM -, Anton Abrosimov wrote: > Steven D'Aprano wrote: > > Why do you want something that isn't a mapping to be usable with mapping > > unpacking? > > I think mapping is not `abc.Mapping` class only. You don't have to inherit from Mapping for this to work.

[Python-ideas] Re: Unpack operator "**" and Mapping

Steven D'Aprano wrote: > On Mon, Dec 28, 2020 at 09:06:40AM -, Anton Abrosimov wrote: > > Steven D'Aprano wrote: > > You contradict yourself: > > "I can implement any behaviour" > > "I can't realize any other behaviour ..." > > Which is correct? > > I apologize for my english, I meant that I

[Python-ideas] Re: Unpack operator "**" and Mapping

On Mon, Dec 28, 2020 at 09:06:40AM -, Anton Abrosimov wrote: > Steven D'Aprano wrote: > > You contradict yourself: > > "I can implement any behaviour" > > "I can't realize any other behaviour ..." > > Which is correct? > > I apologize for my english, I meant that I cannot implement the >

[Python-ideas] Re: Unpack operator "**" and Mapping

Chris Angelico wrote: > Allow me to rephrase what I think you're arguing here, and you can > tell me if I'm close to the mark. You close to the mark. :) Chris Angelico wrote: > Given an object of a custom class C, you can make it usable as "x, y, > z = C()" or "f(*C())" or anything else by

[Python-ideas] Re: Unpack operator "**" and Mapping

Steven D'Aprano wrote: > On Sun, Dec 27, 2020 at 02:05:38PM -, Anton Abrosimov wrote: > > > > *, ** are operators, but behaviorally they are methods or > > functions. I think this is the main problem. > > > > No they aren't operators. They aren't in the operator precedence table, > and

[Python-ideas] Re: Unpack operator "**" and Mapping

On Mon, Dec 28, 2020 at 7:45 PM Anton Abrosimov wrote: > > Steven D'Aprano wrote: > > Why do you want something that isn't a mapping to be usable with mapping > > unpacking? > > I think mapping is not `abc.Mapping` class only. > > What about: > `Iterator[Tuple[str, int]]` > > ``` > @dataclass >

[Python-ideas] Re: Unpack operator "**" and Mapping

Steven D'Aprano wrote: > Why do you want something that isn't a mapping to be usable with mapping > unpacking? I think mapping is not `abc.Mapping` class only. What about: `Iterator[Tuple[str, int]]` ``` @dataclass class MyMap: x: int y: int ``` Is this "mapping"? In Python I can use

[Python-ideas] Re: Unpack operator "**" and Mapping

On Sun, Dec 27, 2020 at 02:05:38PM -, Anton Abrosimov wrote: > 1. `*`, `**` are operators, but behaviorally they are methods or > functions. I think this is the main problem. No they aren't operators. They aren't in the operator precedence table, and they don't have dunders associated with