Re: [Python-Dev] A more flexible task creation

> To be honest, I see "async with" being abused everywhere in asyncio, > lately.  I like to have objects with start() and stop() methods, but > everywhere I see async context managers.> > Fine, add nursery or whatever, but please also have a simple start() / > stop() public API. > > "async with"

Re: [Python-Dev] A more flexible task creation

Le 14/06/2018 à 04:09, Nathaniel Smith a écrit : > How about: > > async def wait_to_run(async_fn, *args): >     await wait_for_something() >     return await async_fn(*args) > > task = loop.create_task(wait_to_run(myfunc, ...)) > It's quite elegant, although figuring out the

Re: [Python-Dev] A more flexible task creation

> > The strict API compatibility requirements of core Python stdlib, coupled > with the very long feature release life-cycles of Python, make me think > this sort of thing perhaps is better built in an utility library on top > of asyncio, rather than inside asyncio itself?  18 months is a long

[Python-Dev] A more flexible task creation

I was working on a concurrency limiting code for asyncio, so the user may submit as many tasks as one wants, but only a max number of tasks will be submitted to the event loop at the same time. However, I wanted that passing an awaitable would always return a task, no matter if the task was

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

Le 25/02/2018 à 14:11, Nikolaus Rath a écrit : > On Feb 25 2018, Chris Angelico wrote: >> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote: >>> On Feb 22 2018, Serhiy Storchaka wrote: 1. Inner generator expression:

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

Le 29/11/2017 à 19:02, Barry Warsaw a écrit : > On Nov 29, 2017, at 12:40, David Mertz wrote: > >> I think some syntax could be possible to only "catch" some exceptions and >> let others propagate. Maybe: >> >>val = name.strip()[4:].upper() except (AttributeError,

Re: [Python-Dev] Python startup optimization: script vs. service

Maybe it's time to bring back the debate on the "lazy" keyword then ? Rendering any statement arbitrarily lazy could help with perfs. It would also make hacks like ugettext_lazy in Django useless. And would render moot the extensions of f-strings for lazily rendered ones. And bring lazy imports in

Re: [Python-Dev] PEP 557: Data Classes

Le 14/09/2017 à 19:24, Mike Miller a écrit : > > On 2017-09-12 21:05, Guido van Rossum wrote: >> It's ironic that some people dislike "data classes" because these are >> regular classes, not just for data, while others are proposing >> alternative names that emphasize the data container aspect.

Re: [Python-Dev] PEP 557: Data Classes

Le 10/09/2017 à 18:36, Eric V. Smith a écrit : > On 9/10/2017 10:00 AM, Michel Desmoulin wrote: >> The reaction is overwhelmingly positive everywhere: hacker news, reddit, >> twitter. > > Do you have a pointer to the Hacker News discussion? I missed it. Err... I may have b

Re: [Python-Dev] PEP 557: Data Classes

The reaction is overwhelmingly positive everywhere: hacker news, reddit, twitter. People have been expecting something like that for a long time. 3 questions: - is providing validation/conversion hooks completely out of the question of still open for debate ? I know it's to keep the

Re: [Python-Dev] PEP 559 - built-in noop()

Don't we already have the mock module for that ? A mowk works as a noop, will be ok with being used as a context manager and allow chaining... Either way, what would a noop function really give you compared to lambda *a, **b: None ? A be bit shorter to write. Maybe faster to run. But do you use

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

Le 09/09/2017 à 01:28, Stefan Krah a écrit : > On Fri, Sep 08, 2017 at 04:04:27PM -0700, Eric Snow wrote: >> * "stdlib support for subinterpreters adds extra burden >> on C extension authors" >> >> In the ``Interpreter Isolation`` section below we identify ways in >> which isolation in

Re: [Python-Dev] for...else

elif break and elif None: I'd like that very much. It's weird a break the semantic of break and None, but it's in such a dark corner of Python anyway I don't bother. Le 27/07/2017 à 21:19, MRAB a écrit : > On 2017-07-27 03:34, Mike Miller wrote: >> >> >> On 2017-07-26 16:36, MRAB wrote: >>>

Re: [Python-Dev] Python startup time

Le 23/07/2017 à 19:36, Brett Cannon a écrit : > > > On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, <desmoulinmic...@gmail.com > <mailto:desmoulinmic...@gmail.com>> wrote: > > > > > Optimizing startup time is incredibly valuable, > >

Re: [Python-Dev] Python startup time

> Optimizing startup time is incredibly valuable, I've been reading that from the beginning of this thread but I've been using python since the 2.4 and I never felt the burden of the startup time. I'm guessing a lot of people are like me, they just don't express them self because "better

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

Last week I had to download a CSV from an FTP and push any update on it using websocket so asyncio was a natural fit and the network part went well. The surprise was that the CSV part would not work as expected. Usually I read csv doing: import csv file_like_object = csv_crawler.get_file() for

Re: [Python-Dev] we would like to share python articles with you

This mailling list is for coordinating the development of the Python programming language, not to be used for marketing. Share your articles on a social network or a forum such as reddit.com/r/python. Le 06/03/2017 à 16:53, Yaroslav Lehenchuk a écrit : > Hi! > > I like your resource. We in

Re: [Python-Dev] When should pathlib stop being provisional?

Fair enough, I stand corrected for both points. Le 07/04/2016 18:13, Zachary Ware a écrit : > On Thu, Apr 7, 2016 at 5:50 AM, Michel Desmoulin > <desmoulinmic...@gmail.com> wrote: >> Path objects don't have splitext() or and don't allow "string" / path. >> Thos

Re: [Python-Dev] When should pathlib stop being provisional?

Le 06/04/2016 22:47, Sven R. Kunze a écrit : > On 06.04.2016 07:00, Guido van Rossum wrote: >> On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote: >>> [...] we can't do: >>> >>> app_root = Path(...) >>> config = app_root/'settings.cfg' >>> with open(config) as

Re: [Python-Dev] Defining a path protocol

Wouldn't be better to generalize that to a "__location__" protocol, which allow to return any kind of location, including path, url or coordinate, ip_address, etc ? Le 06/04/2016 19:26, Brett Cannon a écrit : > WIth Ethan volunteering to do the work to help make a path protocol a > thing -- and

Re: [Python-Dev] why we have both re.match and re.string?

Hi, Le 10/02/2016 22:59, Luca Sangiacomo a écrit : Hi, I hope the question is not too silly, but why I would like to understand the advantages of having both re.match() and re.search(). Wouldn't be more clear to have just one function with one additional parameters like this:

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

Hello, Le 08/02/2016 20:13, Guido van Rossum a écrit : On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner wrote: I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: