[Python-ideas] Re: Exact decimal multiplication and division operations

On Thu, 15 Oct 2020 at 04:22, Guido van Rossum wrote: > > This all seems a pretty artificial argument. > > In plain English, "1/3" is not exactly representable in decimal form, but > something like 0. * 0.22 > *is* (assuming the inputs are what

[Python-ideas] Enhancing Python custom memory allocators

Hi there, Since Python 3.4, once can replace easily the Python memory allocators via the C API with its own copy (https://docs.python.org/3/c-api/memory.html#customize-memory-allocators). This is a great feature for implementing performance optimizations or profiling. This has given the ability t

[Python-ideas] Re: Exact decimal multiplication and division operations

[Tim] >> I suggested following the standards' rules (the constructor works the >> same way as everything else - it rounds) for Python's module too, but >> Mike Cowlishaw (the decimal spec's primary driver) overruled me on >> that. [Greg Ewing ] > Did he offer a rationale for that? Possibly, but I

[Python-ideas] Weakrefs for lru_cache?

Hi everyone, For many years, I've used a `cache` decorator that I built for caching Python functions. Then `functools.lru_cache` was implemented, which is much more standard. However, as far as I know,

[Python-ideas] Weakrefs for lru_cache?

Usually when I use lru_cache I don't want items to randomly disappearing from the cache. Just because a key isn't referenced anywhere else doesn't mean that I want it to automatically disappear. That is the whole point. Take this example: @lru_cache def expensive_function(a,b,c): return a**b**

[Python-ideas] Re: Weakrefs for lru_cache?

Your use case is valid, there are times in which I'd like a strong reference to be kept. But there are also lots of times I want it to not be kept. Then I would offer this feature as a flag `weakref=True` with a default of `False`. What do you think? On Thu, Oct 15, 2020 at 9:10 PM wrote: > Usua

[Python-ideas] Re: Weakrefs for lru_cache?

That would satisfy my concerns. October 15, 2020 2:12 PM, "Ram Rachum" mailto:r...@rachum.com?to=%22Ram%20Rachum%22%20)> wrote: Your use case is valid, there are times in which I'd like a strong reference to be kept. But there are also lots of times I want it to not be kept. Then I would offer t

[Python-ideas] Re: Weakrefs for lru_cache?

On Fri, Oct 16, 2020 at 4:51 AM Ram Rachum wrote: > > Hi everyone, > > For many years, I've used a `cache` decorator that I built for caching Python > functions. Then `functools.lru_cache` was implemented, which is much more > standard. However, as far as I know, it holds normal references to it

[Python-ideas] Re: Weakrefs for lru_cache?

On Thu, 15 Oct 2020 at 19:14, Ram Rachum wrote: > > Your use case is valid, there are times in which I'd like a strong reference > to be kept. But there are also lots of times I want it to not be kept. Then I > would offer this feature as a flag `weakref=True` with a default of `False`. > What

[Python-ideas] Re: Weakrefs for lru_cache?

We have a couple of weak caches In our system, so I see the use case. I don’t like the idea of silently reverting to a strong ref though. I’ve had bad experiences with systems that try to be too helpful in this manner. It seems like a good idea until it becomes a big problem, and then you have

[Python-ideas] Re: Weakrefs for lru_cache?

Agreed. A possible solution is that if given weakref=True and a non-weakreffable key, an exception will be raised when the function attempts to save it in cache. Paul, I'll see if I can give an example use case tomorrow. On Thu, Oct 15, 2020, 21:38 Irit Katriel wrote: > We have a couple of weak

[Python-ideas] Re: Weakrefs for lru_cache?

On Thu, Oct 15, 2020 at 2:16 PM Ram Rachum wrote: > Your use case is valid, there are times in which I'd like a strong > reference to be kept. But there are also lots of times I want it to not be > kept. Then I would offer this feature as a flag `weakref=True` with a > default of `False`. What do

[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

Well, it seems to work now, but the creation from a combined, without holes, dict, is definitively faster no more. On the contrary, it is 2x slower. This is probably because 1. combined dicts needs only one memcpy 2. probably I wrong something in my code, since I need TWO Py_INCREF for keys and v

[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

I forgot: I noticed that creating dict from a matrix N*2 is not optimized for lists and tuples. Is this because creation from a sequence2 is not much used? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ide

[Python-ideas] Re: except-try block

On 11/10/2020 17:20, haael wrote: Very often I use the following construction (especially in operators):     try:     something     except SomeError:     try:     something_else     except AnotherError:     try:     something_completely_different

[Python-ideas] Re: New feature

On 2020-10-13 15:35, Guido van Rossum wrote: Can one of the educators on the list explain why this is such a commonly required feature? I literally never feel the need to clear my screen -- but I've seen this requested quite a few times in various forms, often as a bug report "IDLE does not s

[Python-ideas] Re: except-try block

On Fri, Oct 16, 2020 at 10:45 AM Rob Cliffe via Python-ideas wrote: > One workaround I sometimes use is a pseudo-loop which is executed once > only; whenever the process can be abandoned, I `break` out of the > "loop". It ain't particularly elegant, but it works. Applying to the > OP's example w

[Python-ideas] Re: New feature

I searched my own email archives and found that this is indeed frequently requested for IDLE. For example, Raymond Hettinger filed *two* different bug reports about it on behalf of his students, both closed as duplicates of https://bugs.python.org/issue6143, which has been open with frequent discus

[Python-ideas] Re: Weakrefs for lru_cache?

On Thu, Oct 15, 2020 at 3:33 PM David Mertz wrote: > So the use case needs to be: > > * Function operates on large objects > * Function operates on large, immutable objects > * Function never takes literal or computed arguments (i.e. not > `fun(big1+big2)`) > * Large immutable objects are deleted

[Python-ideas] Re: except-try block

On 16/10/2020 01:36, Chris Angelico wrote: On Fri, Oct 16, 2020 at 10:45 AM Rob Cliffe via Python-ideas wrote: One workaround I sometimes use is a pseudo-loop which is executed once only; whenever the process can be abandoned, I `break` out of the "loop". It ain't particularly elegant, but i

[Python-ideas] Re: except-try block

On Fri, Oct 16, 2020 at 4:37 PM Rob Cliffe via Python-ideas wrote: > Sorry, but I get the impression from your comment (comparing it to goto) > that you think breaking out of a ... let's call it a once-only loop ... > is a Bad Thing and to be discouraged. If I've misunderstood, I > apologise and

[Python-ideas] Re: except-try block

On Fri, Oct 16, 2020 at 02:14:27AM +0100, Rob Cliffe via Python-ideas wrote: > >You mean like a goto statement? I'm not sure what a "pseudo-loop" > >is, other than a way to use break as goto. > > > >ChrisA > > Is that bad?  As I tried to explain, sometimes a process may need to be > abandone