Here's an idea for combining zip_longest with zip strict. Define zip like
so:
def zip(*iterables, strict=False, fill=object())
With no arguments, it's the regular old zip. With `strict=True`, it ensures
the iterators are equal. If you pass in an argument for `fill`, it becomes
zip_longest.
On Su
On Sun, Apr 26, 2020 at 11:56 PM Christopher Barker
wrote:
> > If I have two or more "sequences" there are basically two cases of that.
>
> so you need to write different code, depending on which case? that seems
> not very "there's only one way to do it" to me.
>
This difference is built into t
On Wed, Apr 22, 2020 at 1:22 PM Chris Angelico wrote:
> On Thu, Apr 23, 2020 at 6:18 AM M.-A. Lemburg wrote:
> > >> Instead of keeping values in local variables, you store
> > >> them in the namespace object
> Meaning that every *local* use of those same names now has to be
> adorned with "ns."
On Sun, Apr 26, 2020 at 10:52 AM David Mertz wrote:
> Let me try to explain why I believe that people who think they want
> zip_strict() actually want zip_longest().
>
Thanks for laying it out so clearly. However, reading your post makes it
clear to me that I DO still want zip_strict() :-)
It c
On Mon, Apr 27, 2020 at 12:51 PM Ethan Furman wrote:
>
> On 04/26/2020 05:11 PM, Steven D'Aprano wrote:
> > On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
> >
> >> It's not clear to me why people prefer an extra function which would be
> >> exactly equivalent to lru_cache in the expect
On 04/26/2020 05:11 PM, Steven D'Aprano wrote:
On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
It's not clear to me why people prefer an extra function which would be
exactly equivalent to lru_cache in the expected use case (i.e. decorating a
function without arguments). It seems lik
On Mon, 27 Apr 2020 10:11:01 +1000
Steven D'Aprano wrote:
> On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
>
> > It's not clear to me why people prefer an extra function which would be
> > exactly equivalent to lru_cache in the expected use case (i.e. decorating a
> > function withou
On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:
> It's not clear to me why people prefer an extra function which would be
> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
> function without arguments). It seems like a good way to cause confusion,
> especiall
On Sun, Apr 26, 2020 at 05:31:22PM +0100, Tom Forbes wrote:
> > What if the functions requires arguments? How to cache calls with
> > different arguments? What if some arguments are not hashable?
>
> Then I think lru_cache is perfectly suitable for that use case. `once()`
> would only be useful i
On Mon, Apr 27, 2020 at 9:57 AM Steven D'Aprano wrote:
> I don't especially want zip_whatever to be slow, but the stdlib has
> no obligation to provide a super-fast highly optimized C accelerated
> version of **everything**. Especially not backports. It is perfectly
> acceptable to say:
>
> "Here'
On Sun, Apr 26, 2020 at 04:13:27PM -0700, Andrew Barnert via Python-ideas wrote:
> But if we add methods on zip objects, and then we add a new skip()
> method in 3.10, how does the backport work? It can’t monkeypatch the
> zip type (unless we both make the type public and specifically design
>
On Sun, Apr 26, 2020 at 10:34:27PM +0100, Daniel Moisset wrote:
>- we could add methods to the zip() type that provide different
>behaviours. That way you could use zip(seq, seq2).shortest(), zip(seq1,
>seq2).equal(), zip(seq1, seq2).longer(filler="foo") ; zip(...).shortest()
>woul
On Apr 26, 2020, at 14:36, Daniel Moisset wrote:
>
> This idea is something I could have used many times. I agree with many people
> here that the strict=True API is at least "unusual" in Python. I was thinking
> of 2 different API approaches that could be used for this and I think no one
> ha
This idea is something I could have used many times. I agree with many
people here that the strict=True API is at least "unusual" in Python. I was
thinking of 2 different API approaches that could be used for this and I
think no one has mentioned:
- we could add a callable filler_factory keywo
While the implementation is great, including locking to ensure the underlying
function is called only once, this only works for properties rather than
methods defined in modules (and more generally, any method).
> On 26 Apr 2020, at 20:27, Matthew Einhorn wrote:
>
> On Sun, Apr 26, 2020 at 1:5
On Apr 26, 2020, at 10:49, Eric Fahlgren wrote:
>
>> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
>> It's not clear to me why people prefer an extra function which would be
>> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
>> function without arguments). It see
On Sun, Apr 26, 2020 at 1:54 PM Tom Forbes wrote:
> This is a good idea but some cases need to be lazily evaluated. Without
> that property `once()` loses a lot of utility. In the case of Django some
> of the decorated functions create objects that cannot be instantiated
> until the Django settin
On Sun, Apr 26, 2020 at 7:47 PM Eric Fahlgren
wrote:
> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
>
>> It's not clear to me why people prefer an extra function which would be
>> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
>> function without arguments). It s
Let me try to explain why I believe that people who think they want
zip_strict() actually want zip_longest(). I've already mentioned that I
myself usually want what zip() does not (i.e. zip_shortest()) ... but
indeed not always.
If I have two or more "sequences" there are basically two cases of t
This is a good idea but some cases need to be lazily evaluated. Without that
property `once()` loses a lot of utility. In the case of Django some of the
decorated functions create objects that cannot be instantiated until the Django
settings have been loaded, which rules out calling them from th
On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
> It's not clear to me why people prefer an extra function which would be
> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
> function without arguments). It seems like a good way to cause confusion,
> especially for beg
Since the function has no parameters and is pre-computed, why force all
users to *call* it? The @once decorator could just return the value of
calling the function:
def once(func):
return func()
@once
def pwd():
return os.getcwd()
print(pwd)
On Sun, Apr 26, 2020 at 7:09 AM Tom Forbes w
On Sun, Apr 26, 2020 at 4:42 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> You're missing the topic of the comparison. It is that we could have
>
> removeaffix(source, affix, suffix=True)
> strip(self, chars, where='both') # where in {both, left, right}
>
O
On Sun, Apr 26, 2020 at 6:57 PM Tom Forbes wrote:
> I agree, that was the topic of my original post to the python-ideas
> discussion group[1]. I thought we should special-case `lru_cache()` to
> account for this use case.
>
> The general consensus was that a `once()` decorator would be less
> con
I agree, that was the topic of my original post to the python-ideas discussion
group[1]. I thought we should special-case `lru_cache()` to account for this
use case.
The general consensus was that a `once()` decorator would be less confusing and
more semantically correct than using `lru_cache`
It's not clear to me why people prefer an extra function which would be
exactly equivalent to lru_cache in the expected use case (i.e. decorating a
function without arguments). It seems like a good way to cause confusion,
especially for beginners. Based on the Zen, there should be one obvious way
t
On Sat, Apr 25, 2020 at 10:50 AM Kirill Balunov
wrote:
...the mode switching approach in the current situation looks reasonable,
because the question is how boundary conditions should be treated. I still
prefer three cases switch like `zip(..., mode=('equal' | 'shortest' |
'longest'))`
I like t
What if the functions requires arguments? How to cache calls with
different arguments? What if some arguments are not hashable?
Then I think lru_cache is perfectly suitable for that use case. `once()`
would only be useful if you’re calling a function with no arguments and
therefore return a consta
On Sun, Apr 26, 2020 at 03:03:16PM +0100, Tom Forbes wrote:
> Hello,
> I would like to suggest adding a simple ???once??? method to functools. As
> the name suggests, this would be a decorator that would call the decorated
> function, cache the result and return it with subsequent calls. My rati
I have needed this often enough (and used `lru_cache` ) to say I am
full +1 on it. It should not hurt have `functools.once`.
On Sun, 26 Apr 2020 at 11:09, Tom Forbes wrote:
> Hello,
> I would like to suggest adding a simple “once” method to functools. As the
> name suggests, this would be a de
Hello,
I would like to suggest adding a simple “once” method to functools. As the name
suggests, this would be a decorator that would call the decorated function,
cache the result and return it with subsequent calls. My rationale for
suggesting this addition is twofold:
First: It’s fairly commo
Use := operator (python 3.8+)
https://www.python.org/dev/peps/pep-0572/
niedz., 26 kwi 2020 o 14:37 Николай Мостовенко napisał(a):
>
> Hi to everybody. I was looking for any resolution for my pain in PEP and
> Stack Overflow and can't find an answer. As well the similar ideas here are
> 13 year
Hi to everybody. I was looking for any resolution for my pain in PEP and Stack
Overflow and can't find an answer. As well the similar ideas here are 13 years
old and completely missed.
I feel that I need to create a garbage code doing things like:
```
if myDict.get('spam'):
print(myDict.get('
Kirill Balunov writes:
> Also I don't think that comparison with .rstrip() discussion is
> fair - because in that case, it was proposed to switch two
> completely different approaches (to treat as string vs to treat as
> set of chars) which is too much for just a switch thorugh
> argument. Wh
David Mertz writes:
> If zip_strict() is genuinely what you want to do, an import from
> stdlib is not much effort to get it.
+1. I'm definitely in the camp wanting this to be a new function.
> My belief is that usually people who think they want this actually
> want zip_longest(), but that
35 matches
Mail list logo
