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 strings
> 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.
W
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
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 tha
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 enc
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 com
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 dataclasse
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
> > > >
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 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 copy
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 tr
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 2020-02
> 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 t
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 ha
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 vers
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 mu
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 compil
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 stored
-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 re
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 w
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 hav
21 matches
Mail list logo