Can you try this?
async def __sleep(self):
await None
On Thu, Feb 18, 2021 at 22:31 Luciano Ramalho wrote:
> Follow up question: what's the plan to replace this use of
> `@types.coroutine` in `asyncio/tasks.py`? [1]
>
> @types.coroutine
> def __sleep0():
> ""
> yield
>
> [1]
On Thu, Feb 18, 2021 at 9:39 PM David Mertz wrote:
> As Skip pointed out to me privately, there are some minor limitations with
> this version. E.g.:
>
> % python
> >>> import glob
> >>> import sys
> >>> print 'hello'
> hello
> >>> print 2+2
> 4
> >>> print 2*2
> Unhandled exception: run-time
Follow up question: what's the plan to replace this use of
`@types.coroutine` in `asyncio/tasks.py`? [1]
@types.coroutine
def __sleep0():
""
yield
[1] https://github.com/python/cpython/blob/master/Lib/asyncio/tasks.py#L585
Best,
Luciano
On Fri, Feb 19, 2021 at 2:31 AM Luciano
I've provided this excellent language interpreter as a conda package. For
users of conda, you can install it (on Linux) with:
conda install -c davidmertz python=0.9
(perhaps put it in a different environment than base).
I'm embarrassed by how much effort that took me. I used to teach
On Fri, Feb 19, 2021 at 1:59 AM Guido van Rossum wrote:
>> 1) What Python construct is to be used at the end of a chain of await
>> calls, if not of a generator-based coroutine decorated with
>> `@types.coroutine` and using a `yield` expression in its body?
> At the end of the chain you can call
On Thu, Feb 18, 2021 at 8:23 PM Luciano Ramalho wrote:
> Thanks for your reply, Guido.
>
> On Fri, Feb 19, 2021 at 12:07 AM Guido van Rossum
> wrote:
> > Reading the doc section you link to, it's pretty clear that
> `@asyncio.coroutine` will be removed.
>
> The *Note* right at the top of [1]
Thanks for your reply, Guido.
On Fri, Feb 19, 2021 at 12:07 AM Guido van Rossum wrote:
> Reading the doc section you link to, it's pretty clear that
> `@asyncio.coroutine` will be removed.
The *Note* right at the top of [1] says "Support for generator-based
coroutines is deprecated and is
On Thu, Feb 18, 2021 at 3:57 PM Luciano Ramalho wrote:
> I am not a Python core developer, but my question relates
> to changes that are expected in Python 3.10, so I felt this was the
> best forum to ask. Please let me know if I should discuss this
> elsewhere or file a documentation bug.
>
>
I am not a Python core developer, but my question relates
to changes that are expected in Python 3.10, so I felt this was the
best forum to ask. Please let me know if I should discuss this
elsewhere or file a documentation bug.
First of all, thank you Yuri Selivanov and everybody who contributed
On Thu, 18 Feb 2021 at 17:35, Brandt Bucher wrote:
>
> Thanks for taking the time to work on this, Mark.
Yes, thanks Mark. I'm not sure I've fully understood the PEP yet but I
can see some parts that I definitely like.
> I fear this is at the expense of most simple classes, which currently
Will someone publish an manylinux build to conda-forge (or their own
channel)?
On Thu, Feb 18, 2021 at 9:15 PM Dan Stromberg wrote:
>
> On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky
> wrote:
>
>> I think to resolve this issue to the completion, and avoid possibility
>> of an intermediary to
On Thu, Feb 18, 2021 at 12:02 AM Paul Sokolovsky wrote:
> I think to resolve this issue to the completion, and avoid possibility
> of an intermediary to add any unexpected changes/mistakes to the
> original sources, instead of "someone making a tarball", someone should
> make a script, which
Brandt Bucher wrote:
> For a pattern with no positional subpatterns, such as like `C()` or `C(x=x,
> y=y, z=z)`: ...
> It also appears that we lose a lot of expressive "idioms" by requiring
> `__attributes__` to be complete.
> This also means that matching classes like `types.SimpleNamespace`
Thanks for taking the time to work on this, Mark.
Overall, I'm skeptical of this proposal. It seems like it takes a lot of
"simple" things and makes them quite complex, and takes many "static" things
and makes them quite dynamic. I feel that it also misrepresents certain aspects
of PEP 634.
Hi everyone,
I'd like to announce a new PEP.
https://www.python.org/dev/peps/pep-0653/
It builds on PEP 634 (Structural Pattern Matching: Specification), adding:
More precise semantics.
A bit more customization for complex classes.
Its also a bit more robust and should be faster (eventually).
On Thu, Feb 18, 2021 at 10:10 AM Larry Hastings wrote:
> Call me crazy, but... shouldn't they be checked in? I thought we literally
> had every revision going back to day zero. It should be duck soup to
> recreate the original sources--all you need is the correct revision number.
It seems to
On 2/17/21 4:45 PM, Brett Cannon wrote:
If we can get a clean copy of the original sources I think we should
put them up under the Python org on GitHub for posterity.
Call me crazy, but... shouldn't they be checked in? I thought we
literally had every revision going back to day zero. It
On 18.02.2021 09:16, M.-A. Lemburg wrote:
> On 18.02.2021 01:45, Brett Cannon wrote:
>> If we can get a clean copy of the original sources I think we should put
>> them up
>> under the Python org on GitHub for posterity.
>
> There is already a page with Andrew's build on python.org:
>
>
On 18.02.2021 01:45, Brett Cannon wrote:
> If we can get a clean copy of the original sources I think we should put them
> up
> under the Python org on GitHub for posterity.
There is already a page with Andrew's build on python.org:
https://www.python.org/download/releases/early/
but it's not
Hello,
On Wed, 17 Feb 2021 18:53:46 -0600
Skip Montanaro wrote:
> > If we can get a clean copy of the original sources I think we
> > should put them up under the Python org on GitHub for posterity.
>
> Did that earlier today:
>
> https://github.com/python/pythondotorg/issues/1734
I think
20 matches
Mail list logo
