On Mon, Feb 10, 2020 at 9:50 AM Andrew Barnert via Python-ideas
wrote:
> It’s a well-known problem that async is “contagious”: [...]
>
> But C# and every other language that’s borrowed the idea has the same
> problem, and as far as I know, nobody’s thought of a good answer yet.
Threads don't
There are already several libraries which improve tracebacks in various ways,
including the standard library module `cgitb`. These libraries often simply
include multiple lines surrounding the primary one, which in most cases will
give you the context you need and maybe some extra.
I recently
-Original Message-
From: Chris Angelico
Sent: 10 February 2020 18:16
To: python-ideas
Subject: [Python-ideas] Re: PyPI should include PEP 440-compliant version
strings for including in install_requires
On Tue, Feb 11, 2020 at 5:00 AM Christopher Barker wrote:
>
> > there are many
On 2/10/20 1:25 PM, Chris Angelico wrote:
On Tue, Feb 11, 2020 at 5:19 AM Andrew Barnert via Python-ideas
wrote:
Meanwhile, for the implementation side, I don’t think there’s an issue with how
traceback passes data around, but with what’s available in the first place.
Look at what gets
On Tue, Feb 11, 2020 at 5:19 AM Andrew Barnert via Python-ideas
wrote:
> Meanwhile, for the implementation side, I don’t think there’s an issue with
> how traceback passes data around, but with what’s available in the first
> place. Look at what gets stored as line number information in a
On Feb 10, 2020, at 09:57, Henk-Jaap Wagenaar
wrote:
>
> Any particular reason this is not possible or done? I'm guessing it would
> require quite a bit of restructuring in the traceback object/module
One problem is not the implementation, but the interface: if you expand _every_
step into
On Tue, Feb 11, 2020 at 5:00 AM Christopher Barker wrote:
>
> > there are many reasons to at least specify a minimum version
>
> Yes, but I think your proposal would encourage people to pin to the latest
> version as a minimum, which would be unfortunate.
>
> I like the maxim:
> “don’t pin a
On 2020-02-10 2:59 p.m., Christopher Barker wrote:
> there are many reasons to at least specify a minimum version
Yes, but I think your proposal would encourage people to pin to the
latest version as a minimum, which would be unfortunate.
I like the maxim:
“don’t pin a version unless you
> there are many reasons to at least specify a minimum version
Yes, but I think your proposal would encourage people to pin to the latest
version as a minimum, which would be unfortunate.
I like the maxim:
“don’t pin a version unless you have a good reason, and you’ve thought
about what version
I wonder why async needed to be like it is.
await foo(...) could have turned into something like foo.__await__(...)
and had foo.__call__ just run the function anyway until actual yielding
is necessary (at which point, raise RuntimeError).
oh well, can't change that now I guess. :/
On
Dear Ideas,
TL;DR include multiple lines in traceback when appropriate (expressions
broken up over multiple lines) to make it easier to spot error from looking
at traceback
Apologies if this has been suggested/discussed before. I am suggesting that
if you do:
```
[
x for x in 0
]
```
the
> On Feb 10, 2020, at 02:34, Bar Harel wrote:
>
> While I'm not this idea can totally work, I do think we need a method of
> closing the gap between asyc coroutines and normal functions.
>
> As of today, async applications need to create an entirely different
> codebase, sometimes just by
On 2020-02-10 2:03 a.m., Anders Hovmöller wrote:
> On 10 Feb 2020, at 04:18, Soni L. wrote:
>
> Traits are composition tho. I think you missed something I said.
In that case I think we all missed it and then isn't that on you? Remember it
is you who are trying to convince the list so any
On Mon, Feb 10, 2020 at 9:30 AM wrote:
> It's been two years since this proposal has been postponed - I would like
> to revive it.
>
> > > > ...I propose the addition of a keyword_only flag to the
> > > > @dataclass decorator that renders the __init__ method using
> > > >
It's been two years since this proposal has been postponed - I would like to
revive it.
A quick recap (quotes edited for brevity):
> > > On 23 January 2018 at 03:33, George Leslie-Waksman
> > > mailto:waks...@gmail.com> wrote:
> > >
> > > The proposed implementation of
On 2020-02-10 9:15 a.m., Soni L. wrote:
[...]
I think they mean that instead of e.g.
https://pypi.org/project/six/ just showing `pip install six`, it
should also show example install_requires values. E.g.
`install_requires: ['six~=1.14.0']`. Or maybe a dropdown where you
select the
On 2020-02-10 6:13 a.m., Cameron Simpson wrote:
On 10Feb2020 18:26, Chris Angelico wrote:
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn
wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. wrote:
> Figuring out versioning is hard. PyPI should
On 2/10/20 2:26 AM, Chris Angelico wrote:
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. wrote:
Figuring out versioning is hard. PyPI should encourage semver by
including PEP 440 version strings
While I'm not sure this idea can totally work, I do think we need a method
of closing the gap between asyc coroutines and normal functions.
As of today, async applications need to create an entirely different
codebase, sometimes just by copy and paste, while changing function
definitions to async
> 2. I couldn't wrap my head around the async/await and future constructs
particularly quickly, and I was concerned that my team would also struggle
with this change.
> 3. I believe the procedural style glue code we have is quite easy to
comprehend, which I think has a positive impact on scale.
On 10Feb2020 18:26, Chris Angelico wrote:
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn wrote:
On Sun, Feb 9, 2020, 11:03 AM Paul Moore wrote:
On Sun, 9 Feb 2020 at 14:39, Soni L. wrote:
> Figuring out versioning is hard. PyPI should encourage semver by
> including PEP 440 version
21 matches
Mail list logo
