On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
> >How many beginners do you know who even know what a LRU cache is?
>
> How many beginners know they want to call a function only once?
More than the number who know about LRU caches.
Ethan, are you objecting to a self-descriptive n
On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
How many beginners know they want to call a function only once?
More than the number who know about LRU caches.
Ethan, are you objecting to a self-descriptive name because it is too
On 04/26/2020 08:56 PM, Christopher Barker wrote:
that seems not very "there's only one way to do it" to me.
The quote is "one obvious way".
It almost feels like the proponents of the new mode/function are hoping to avoid the
processing that might need to be "rolled back" in some manner if
> On 27 Apr 2020, at 16:01, Ethan Furman wrote:
>
> On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
>> On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
>
>>> How many beginners know they want to call a function only once?
>> More than the number who know about LRU caches.
>> Ethan
On Apr 26, 2020, at 16:58, Steven D'Aprano wrote:
>
> 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
On 04/27/2020 08:26 AM, Barry wrote:
On 27 Apr 2020, at 16:01, Ethan Furman wrote:
I'm objecting to using "beginners" as the basis for name choices for advanced
topics.
Aside from that, `once` is a fine name. I'm sure it means that a function can
only be defined once, and subsequent defini
On Apr 26, 2020, at 21:23, David Mertz wrote:
>
>
>> 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'
On Mon, 27 Apr 2020 09:26:53 -0700
Ethan Furman wrote:
>
> > Or are you saying that once could be interpreted to mean I cannot do that
> > 2nd def?
>
> That is what I was saying -- that `once`, all by itself, could mean multiple
> things.
That's a good point. A more explicit spelling would
On 04/27/2020 11:34 AM, Antoine Pitrou wrote:
On Mon, 27 Apr 2020 09:26:53 -0700 Ethan Furman wrote:
That is what I was saying -- that `once`, all by itself, could mean multiple
things.
That's a good point. A more explicit spelling would be `@call_once`,
what do you think?
I think that's
I would think that would be a great name, it’s more explicit and fits more in
with its siblings “lru_cache” and “cached_property”.
Not to imply that there is a consensus to move forward, I would be interested
in knowing what the next steps would be if there was. Would this require a PEP
to be s
My own opinion is that it's limited enough in scope (and probably
uncontroversial implementation-wise) that it doesn't need a PEP. Of
course other core developers may disagree, so perhaps wait a few days
before submitting a PR :-)
Regards
Antoine.
On Mon, 27 Apr 2020 20:16:53 +0100
Tom Forbes
I wanna propose making generators even weirder!
so, extended continue is an oldie:
https://www.python.org/dev/peps/pep-0342/#the-extended-continue-statement
it'd allow one to turn:
yield from foo
into:
for bar in foo:
continue (yield bar)
but what's this extended for-else?
On Sun, Apr 26, 2020 at 9:21 PM David Mertz wrote:
> 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 on
On Mon, Apr 27, 2020 at 12:26 PM Antoine Pitrou wrote:
> My own opinion is that it's limited enough in scope (and probably
> uncontroversial implementation-wise) that it doesn't need a PEP. Of
> course other core developers may disagree, so perhaps wait a few days
> before submitting a PR :-)
>
I'd like to give my explicit +1 on this proposal, and for the
suggested alternative name "call_once". To me, this seems to be the
case of a common small startup optimization that's very easy to get
wrong, and to many users may be too much of a hassle to write their
own implementation to be worth us
Christopher Barker wrote:
> Is there a core developer with a particular interest in functools to be
> consulted?
Yep, Raymond Hettinger is the designated expert for the functools
module. See https://devguide.python.org/experts/#stdlib. I'm not sure
as to whether he regularly checks python-ideas,
On 27/04/2020 21:39, Christopher Barker wrote:
To me, having a zip_equal that iterates through the inputs on demand, and
checks when one is exhausted, rather than pre-determining the lengths ahead
of time will solve almost all (or all? I can't think of an example where it
wouldn't) use cases
Ex
On Mon, Apr 27, 2020 at 4:39 PM Christopher Barker
wrote:
> Isn't there? There are many cases where you CANNOT (or don't want to, for
> performance reasons) "consume" the entirely of the inolut iterators, and
> many cases where it would be fine to do that. But are there many (any?)
> cases where
On Apr 27, 2020, at 12:49, Soni L. wrote:
>
> I wanna propose making generators even weirder!
Why? Most people would consider that a negative, not a positive. Even if you
demonstrate some useful functionality with realistic examples that benefit from
it, all you’ve done here is set the bar hi
On 2020-04-27 6:11 p.m., Andrew Barnert wrote:
On Apr 27, 2020, at 12:49, Soni L. wrote:
>
> I wanna propose making generators even weirder!
Why? Most people would consider that a negative, not a positive. Even if you
demonstrate some useful functionality with realistic examples that bene
Thank you Kyle and everyone else who chimed in here. I’ve made a post to the
python-dev mailing list - it has yet to appear, but perhaps it’s in a
moderation queue. I’ll ensure it’s posted tomorrow.
Tom
> On 27 Apr 2020, at 21:56, Kyle Stanley wrote:
>
> Christopher Barker wrote:
>> Is there
On Tue, Apr 28, 2020 at 7:41 AM Soni L. wrote:
> I haven't found a real use-case for this yet, tho.
So maybe hold off until you have one?
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-l
On Apr 27, 2020, at 13:41, Christopher Barker wrote:
>
> SIDE NOTE: this is reminding me that there have been calls in the past for an
> optional __len__ protocol for iterators that are not proper sequences, but DO
> know their length -- maybe one more place to use that if it existed.
But __le
the point of posting here is to find other use-cases! there's a reason
this isn't a PEP!
On 2020-04-27 7:14 p.m., Chris Angelico wrote:
On Tue, Apr 28, 2020 at 7:41 AM Soni L. wrote:
> I haven't found a real use-case for this yet, tho.
So maybe hold off until you have one?
ChrisA
___
Also, just to clearly demonstrate how the walrus operator could be
used for the OP's examples:
original:
```
if myDict.get('spam'):
print(myDict.get('spam'))
```
walrus:
```
if (x := d.get("spam")):
print(x)
```
original:
```
x = myDict.get('spam')
if x is not None:
print(x)
```
walru
the point of posting here is that someone else may have a similar
existing use-case where this would make things better. I can't take a
look at proprietary code so I post about stuff in the hopes that the ppl
who can will back this stuff up.
(doesn't proprietary software make things so much ha
On Apr 27, 2020, at 14:38, Soni L. wrote:
[snipping a long unanswered reply]
> The explicit case for zip is if you *don't* want it to consume anything after
> the stop.
Sure, but *when do you want that*? What’s an example of code you want to write
that would be more readable, or easier to wri
I doubt that you will find many people on this list who are willing to do your
homework for you. It will be very hard to convince most of the people on this
list if the only reason you can give is "I think this would look great". Great
ideas are based on real needs, not on flights of fancy.
O
On Apr 27, 2020, at 16:35, Soni L. wrote:
>
> the point of posting here is that someone else may have a similar existing
> use-case
Similar to *what*? It can’t be similar to your use case if you don’t have a use
case for it to be similar to.
If you really can’t imagine why something might be
On Tue, Apr 28, 2020 at 9:16 AM Soni L. wrote:
>
> the point of posting here is to find other use-cases! there's a reason
> this isn't a PEP!
>
Once again, a massive misunderstanding of the PEP process. Ideas have
to actually be worth pursuing long before they become PEPs, and not
all ideas need
On 2020-04-27 8:37 p.m., Andrew Barnert wrote:
On Apr 27, 2020, at 14:38, Soni L. wrote:
[snipping a long unanswered reply]
> The explicit case for zip is if you *don't* want it to consume anything after
the stop.
Sure, but *when do you want that*? What’s an example of code you want to wri
On 28/04/20 6:34 am, Antoine Pitrou wrote:
A more explicit spelling would be `@call_once`,
what do you think?
That's not quite right either -- you're allowed to *call* it
as many times as you want. It's more like "execute once".
But that's a rather long and awkward name.
I don't think "once" i
On Mon, Apr 27, 2020 at 07:58:54AM -0700, Ethan Furman wrote:
> On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
> >On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
>
> >>How many beginners know they want to call a function only once?
> >
> >More than the number who know about LRU cache
On Tue, Apr 28, 2020 at 12:40:34PM +1200, Greg Ewing wrote:
> I don't think "once" is a bad name, but we shouldn't kid
> ourselves that it will be intuitive or discoverable to
> anyone who isn't familiar with Eiffel.
I'm not particularly wedded to "once" specifically, but honestly I think
that i
On Sun, Apr 26, 2020 at 09:58:46PM -0400, Dan Sommers wrote:
> > How many beginners do you know who even know what a LRU cache is?
>
> The same number of beginners who know to look in functools for a
> decorator called once?
Look in *functools* at all? Probably not that many.
Google for "how do
On Apr 27, 2020, at 17:01, Soni L. wrote:
>
>>> On 2020-04-27 8:37 p.m., Andrew Barnert wrote:
>>> On Apr 27, 2020, at 14:38, Soni L. wrote:
>> [snipping a long unanswered reply]
>>> The explicit case for zip is if you *don't* want it to consume anything
>>> after the stop.
>> Sure, but *when d
On 2020-04-28 12:28 a.m., Andrew Barnert wrote:
On Apr 27, 2020, at 17:01, Soni L. wrote:
>
>>> On 2020-04-27 8:37 p.m., Andrew Barnert wrote:
>>> On Apr 27, 2020, at 14:38, Soni L. wrote:
>> [snipping a long unanswered reply]
>>> The explicit case for zip is if you *don't* want it to consu
On 28/04/20 1:17 pm, Steven D'Aprano wrote:
I think
that it is silly to say that you have to be familiar with Eiffel to
recognise the connection between running a function once and the word
"once".
The connection is very obvious after you know about it.
And probably you can guess the meaning if
On Apr 27, 2020, at 20:48, Soni L. wrote
>
>> Here are four ways of doing this today:
…
>> So, why do we need another way to do something that’s probably pretty
>> uncommon and can already be done pretty easily? Especially if that new way
>> isn’t more readable or more powerful?
>
> the only
39 matches
Mail list logo
