On Thu, Dec 9, 2021 at 6:01 PM Christopher Barker wrote:
>
>
>> My Option 1 (future statement, deprecation of early binding, and permanent
>> switch to late binding): +
>
>
> I have no authority about this at all, and a negligible amount of influence,
> but I’ve been around Python a long time:
On Thu, Dec 9, 2021 at 5:54 PM Brendan Barnwell wrote:
>
> On 2021-12-08 20:36, Chris Angelico wrote:
> > Remember, though: The comparison should be to a function that looks like
> > this:
> >
> > def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
> > if b is _SENTINEL1: b = {}
> >
On Thu, Dec 9, 2021 at 5:52 PM Brendan Barnwell wrote:
>
> On 2021-12-08 20:55, Chris Angelico wrote:
> > (H) This is true. But if the two syntaxes can be sufficiently similar,
> > the cost should be low, and the feature benefit would be high. Early
> > binding lets you "def f(x=x):" in a loop
> My Option 1 (future statement, deprecation of early binding, and permanent
> switch to late binding): +
>
I have no authority about this at all, and a negligible amount of
influence, but I’ve been around Python a long time:
That is not going to happen.
Way too much of a breaking change, and
On 2021-12-08 20:36, Chris Angelico wrote:
Remember, though: The comparison should be to a function that looks like this:
def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
if b is _SENTINEL1: b = {}
if c is _SENTINEL2: c = some_function(a, b)
if d is _SENTINEL3: d =
On 2021-12-08 20:55, Chris Angelico wrote:
(H) This is true. But if the two syntaxes can be sufficiently similar,
the cost should be low, and the feature benefit would be high. Early
binding lets you "def f(x=x):" in a loop and capture each x as it goes
by. Late binding lets you "def f(x=>[]):"
(I started writing this this morning, and there’s been quite a bit more
discussion since, but I don’t think it’s completely too late)
Thanks Paul (and others that have commented). All reasonable
considerations, and of course what the SC will be thinking about. However,
a key question.
> 4. It's
On Thu, 2021-12-09 at 12:32 +1100, Steven D'Aprano wrote:
> On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
>
> > I propose there is already a viable option in typing.Annotated.
> > Example:
> >
> > @dataclass
> > class InventoryItem:
> > """Class for keeping track of an item in
On Thu, Dec 9, 2021 at 3:16 PM Rob Cliffe via Python-ideas
wrote:
>
> Objections to PEP 671 - Summary
> There seems to be a problem understanding what the objections to PEP 671 are.
> Chris A wrote:
> "Part of the problem is that it is really REALLY hard to figure out what the
> actual
On Wed, Dec 8, 2021 at 11:28 PM Chris Angelico wrote:
> On Thu, Dec 9, 2021 at 3:15 PM Jonathan Goble wrote:
> > My preferences to resolve this are, in order:
> >
> > 1. Introduce `from __future__ import late_default`. When present,
> argument defaults in that file are late bound instead of
On Thu, Dec 9, 2021 at 2:22 PM Brendan Barnwell wrote:
> Your example there is very simple. But for me a lot of it comes down
> to this:
>
> def f(a=[], b@={}, c=some_function(a, b), d@=other_function(a, b, c)):
>
> The PEP envisions a world in which you can have a list of
On Thu, Dec 9, 2021 at 2:10 PM David Mertz, Ph.D. wrote:
>
> Easy! Look at EVERY Python function that uses a sentinel. They all get a
> little bit worse under your proposal.
>
> On Wed, Dec 8, 2021, 9:54 PM Chris Angelico
>>
>> > An obvious reason to oppose it is that it is a much worse way of
On Thu, Dec 9, 2021 at 3:15 PM Jonathan Goble wrote:
> My preferences to resolve this are, in order:
>
> 1. Introduce `from __future__ import late_default`. When present, argument
> defaults in that file are late bound instead of early bound. After a suitable
> deprecation period, make the
_*Objections to PEP 671 - Summary*_
There seems to be a problem understanding what the objections to PEP 671
are. Chris A wrote:
"Part of the problem is that it is really REALLY hard to figure out what
the actual objections are. I asked, and the one clear answer I got was
one subjective
Let me go back to the top and answer the original questions, then offer a few
thoughts that have been germinating in my head through this discussion.
Chris Angelico wrote:
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference
Chris Angelico writes:
> Please explain to me *exactly* what your arguments against the current
> proposal are.
No, thank you. They're all in the thread. Managing the thread is
your job as proponent.
In brief, my issues are introspection, adding syntax, the particular
syntax "=>". If you
On 2021-12-08 15:17, Chris Angelico wrote:
>At a minimum, the PEP should state the objections fairly, and note
>that the PEP author disagrees. A PEP isn't a sales pitch, it's a
>summary of the discussions - so it absolutely should mention that
>there's been significant opposition to the
Easy! Look at EVERY Python function that uses a sentinel. They all get a
little bit worse under your proposal.
On Wed, Dec 8, 2021, 9:54 PM Chris Angelico
> > An obvious reason to oppose it is that it is a much worse way of writing
> an existing sentinel check.
> This is what I want to see an
On Thu, Dec 9, 2021 at 1:49 PM David Mertz, Ph.D. wrote:
>
> That's correct Chris!
>
> No matter how much you try to change the topic, I was asked how a general
> deferred concept would be useful and gave an example.
>
I've never denied that it would be useful in general, just that it has
That's correct Chris!
No matter how much you try to change the topic, I was asked how a general
deferred concept would be useful and gave an example.
As the example itself shows, obviously there ARE other ways one could do it
(as I did in the code linked). And there are ways it could be improved
On Thu, Dec 9, 2021 at 12:41 PM MRAB wrote:
>
> On 2021-12-08 23:39, Chris Angelico wrote:
> > On Thu, Dec 9, 2021 at 10:35 AM Paul Moore wrote:
> >>
> >> On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> >> > Part of the problem is that it is really REALLY hard to figure out
> >> > what the
On Thu, Dec 9, 2021 at 11:47 AM David Mertz, Ph.D.
wrote:
>
> There are tens of concrete examples at the link I gave, and hundreds more you
> can find easily by searching on Dask Delayed. This feels more like trying to
> believe a contrary than seeking understanding.
>
> Here's a concrete
On 2021-12-08 23:39, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 10:35 AM Paul Moore wrote:
On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> Part of the problem is that it is really REALLY hard to figure out
> what the actual objections are. I asked, and the one clear answer I
> got was
On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
> I propose there is already a viable option in typing.Annotated.
> Example:
>
> @dataclass
> class InventoryItem:
> """Class for keeping track of an item in inventory."""
>
> name: Annotated[str, "Short name of the
On 9/12/21 12:50 am, tmkehrenb...@gmail.com wrote:
The main criticism, I think, was that it is weird to have the docstring
*below* the attribute.
I don't think that's a problem. The docstring of a class or function
is also below the name of the class or function. I think it's
actually more
On 9/12/21 2:07 am, TobiasHT wrote:
If a function fails to be inlined at compiletime due to dynamic behavior of
python, then the normal function call behavior can be the fallback
The problem is that the compiler might *think* it knows where the
module is at compile time, but at run time it
There are tens of concrete examples at the link I gave, and hundreds more
you can find easily by searching on Dask Delayed. This feels more like
trying to believe a contrary than seeking understanding.
Here's a concrete example that I wrote last summer. I wanted to write a
similar program in a
On Thu, Dec 9, 2021 at 10:35 AM Paul Moore wrote:
>
> On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> > Part of the problem is that it is really REALLY hard to figure out
> > what the actual objections are. I asked, and the one clear answer I
> > got was one subjective opinion that the
On 12/8/2021 2:40 PM, Brendan Barnwell wrote:
On 2021-12-08 09:59, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
wrote:
But the "good idea" of general deferreds is only marginally relevant
to our -1s. It's those -1s that constitute the main issue for Chris,
since
On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> Part of the problem is that it is really REALLY hard to figure out
> what the actual objections are. I asked, and the one clear answer I
> got was one subjective opinion that the cognitive load exceeded the
> benefit. Great! That's one person's
On 08/12/2021 23:09, David Mertz, Ph.D. wrote:
On Wed, Dec 8, 2021, 5:55 PM Rob Cliffe via Python-ideas
But AIUI (i.e. practically not at all) Dask is about parallel
computing, which is not the same thing as deferred evaluation,
though doubtless they overlap. Again AIUI, parallel
On Thu, Dec 9, 2021 at 10:07 AM Paul Moore wrote:
>
> On Wed, 8 Dec 2021 at 22:53, Chris Angelico wrote:
>
> > Most of that is a *massive* YAGNI as regards function default
> > arguments. We do not need parallel execution just to figure out the
> > length of a list passed as a previous
On Wed, Dec 8, 2021, 5:55 PM Rob Cliffe via Python-ideas
> But AIUI (i.e. practically not at all) Dask is about parallel computing,
> which is not the same thing as deferred evaluation, though doubtless they
> overlap. Again AIUI, parallel computing is mainly useful when you have
> multiple
On Wed, 8 Dec 2021 at 22:53, Chris Angelico wrote:
> Most of that is a *massive* YAGNI as regards function default
> arguments. We do not need parallel execution just to figure out the
> length of a list passed as a previous parameter. So you've just added
> weight to my argument that a generic
On Wed, 8 Dec 2021 at 19:59, Rob Cliffe via Python-ideas
wrote:
>
> On 08/12/2021 19:27, Paul Moore wrote:
> >
> > The reason deferred objects keep coming up is because they *do* have a
> > much more compelling benefit - they help in a much broader range of
> > cases.
> That may be true. I don't
On Thu, Dec 9, 2021 at 9:44 AM David Mertz, Ph.D. wrote:
>
> On Wed, Dec 8, 2021, 2:58 PM Rob Cliffe via Python-ideas
>>
>> On 08/12/2021 19:27, Paul Moore wrote:
>> > The reason deferred objects keep coming up is because they *do* have a
>> > much more compelling benefit - they help in a much
Thank you David.
But AIUI (i.e. practically not at all) Dask is about parallel computing,
which is not the same thing as deferred evaluation, though doubtless
they overlap. Again AIUI, parallel computing is mainly useful when you
have multiple cores or multiple computers.
Can anyone give
On Wed, Dec 8, 2021, 2:58 PM Rob Cliffe via Python-ideas
> On 08/12/2021 19:27, Paul Moore wrote:
> > The reason deferred objects keep coming up is because they *do* have a
> much more compelling benefit - they help in a much broader range of cases.
>
Can anyone provide some realistic use cases?
On Wed, Dec 8, 2021, 1:09 PM Chris Angelico
> Please explain to me *exactly* what your arguments against the current
> proposal are. At the moment, I am extremely confused as to what people
> actually object to,
Cognitive burden ≫ potential benefit.
On 2021-12-08 09:59, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
wrote:
But the "good idea" of general deferreds is only marginally relevant
to our -1s. It's those -1s that constitute the main issue for Chris,
since they're a noisy signal that the SC might think
On 2021-12-06 11:21, Chris Angelico wrote:
On Tue, Dec 7, 2021 at 6:16 AM Brendan Barnwell wrote:
On 2021-12-05 08:14, Chris Angelico wrote:
> Closures cannot be executed without a context. Consider:
>
> def f(x=lambda: (a:=[])):
> if isinstance(x, FunctionType): x = x()
> print(a)
On 08/12/2021 19:27, Paul Moore wrote:
The reason deferred objects keep coming up is because they *do* have a
much more compelling benefit - they help in a much broader range of
cases.
That may be true. I don't know.
Can anyone provide some realistic use cases? I've read the whole thread
On 2021-12-08 09:59, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
wrote:
But the "good idea" of general deferreds is only marginally relevant
to our -1s. It's those -1s that constitute the main issue for Chris,
since they're a noisy signal that the SC might think
On Wed, 8 Dec 2021 at 18:09, Chris Angelico wrote:
>
> On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
> wrote:
> > But the "good idea" of general deferreds is only marginally relevant
> > to our -1s. It's those -1s that constitute the main issue for Chris,
> > since they're a noisy signal
On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan wrote:
> I believe a Annotated[..., str] could become an attribute docstring if by
> consensus we deem it to be so. I can't see any disadvantages, perhaps save
> for the verbosity of `Annotated`. It certainly seems like an advantage to
> use an existing
I believe a Annotated[..., str] could become an attribute docstring if
by consensus we deem it to be so. I can't see any disadvantages,
perhaps save for the verbosity of `Annotated`. It certainly seems like
an advantage to use an existing mechanism rather than define a new one
that would appear to
On Wed, Dec 8, 2021 at 12:46 PM Paul Bryan wrote:
> I propose there is already a viable option in typing.Annotated. Example:
>
> @dataclass
>
> class InventoryItem:
>
> """Class for keeping track of an item in inventory."""
>
> name: Annotated[str, "Short name of the item."]
>
>
On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
wrote:
> But the "good idea" of general deferreds is only marginally relevant
> to our -1s. It's those -1s that constitute the main issue for Chris,
> since they're a noisy signal that the SC might think as we do.
Please explain to me *exactly*
Rob Cliffe via Python-ideas writes:
> On 07/12/2021 18:22, Stephen J. Turnbull wrote:
> > For values of "hard" == "non-trivial but mostly bikeshedding". I
> > don't think it will be that much harder to get through than Chris's.
> >
> > And in theory it could be easier: it could be
On Wed, Dec 08, 2021 at 11:50:55AM -, tmkehrenb...@gmail.com wrote:
> A few weeks ago, I proposed on this mailing list to write docstrings for
> class attributes like this:
>
> @dataclass
> class A:
> x: int
> """Docstring for x."""
> ... is a normal string, except that it is stored
I propose there is already a viable option in typing.Annotated.
Example:
@dataclass
class InventoryItem:
"""Class for keeping track of an item in inventory."""
name: Annotated[str, "Short name of the item."]
unit_price: Annotated[float, "Price per unit in dollar."]
...
I've
On Wed, Dec 8, 2021 at 8:41 AM Steven D'Aprano wrote:
> On Wed, Dec 08, 2021 at 11:50:55AM -, tmkehrenb...@gmail.com wrote:
> > A few weeks ago, I proposed on this mailing list to write docstrings for
> > class attributes like this:
> >
> > @dataclass
> > class A:
> > x: int
> >
On Wed, Dec 08, 2021 at 11:50:55AM -, tmkehrenb...@gmail.com wrote:
> A few weeks ago, I proposed on this mailing list to write docstrings for
> class attributes like this:
>
> @dataclass
> class A:
> x: int
> """Docstring for x."""
>
> The main criticism, I think, was that it is
I think it's an interesting idea. I made the same or at least similar
suggestion in the previous thread, but it didn't receive any responses. I
assume this is because people weren't very interested (but I also
understand people are busy).
Here's that message:
> What inlining usually means is to copy the body of the function
> in place of the call, with appropriate parameter substitutions.
> That would eliminate most of the overhead of a function call, but
> there are problems with doing it in Python. Imported modules would
> have to be located and
So for the point of benchmarks, This is a link to some of the hacks developed
by Pythonistas to boost some python speed. Among the hacks, there's a topics
called "reducing dots" and "local variables".
https://wiki.python.org/moin/PythonSpeed/PerformanceTips
Also I would explain to a pythonista
A few weeks ago, I proposed on this mailing list to write docstrings for
class attributes like this:
@dataclass
class A:
x: int
"""Docstring for x."""
The main criticism, I think, was that it is weird to have the docstring
*below* the attribute.
To solve this problem, I propose to
On 9/12/21 12:03 am, Steven D'Aprano wrote:
does that mean that the compiler will translate the above to:
def eggs(a, b, c):
def spam(*args):
# Do something with args...
thing = spam(a, b, c)
...
If that's what's intended, it wouldn't really be an
Hi Tobias,
On Wed, Dec 08, 2021 at 05:53:56AM -, TobiasHT wrote:
> The Python community has a 5 year plan to push the limit of speed in
> Python. One of the things that reduces Python execution speed is
> calling methods or functions that are not in the nearest scope.
Do you have some
59 matches
Mail list logo
