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 ben
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 i
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 introd
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 t
> 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 parse
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:
https://mail.python.org/archives/list
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 weir
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
> > """Do
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 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 in
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 implemente
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*
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."]
>
> u
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 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 m
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 th
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 as
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
a
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 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 as
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 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?
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 examp
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 br
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 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, 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 cores
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 parameter.
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 c
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 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 th
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 cogni
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 bun
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 tur
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 cons
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 item."]
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 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 exampl
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
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 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
nothin
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 exa
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 proposal,
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 we
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
_*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 opinio
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 futur
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 wr
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 argumen
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 earl
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 objectio
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
(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 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=>[]):" a
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 = other_fun
> 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 ea
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 and
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 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:
>
59 matches
Mail list logo
