Steven D'Aprano writes:
> On Thu, Mar 17, 2022 at 01:21:24AM +0900, Stephen J. Turnbull wrote:
>
> > MRAB writes:
> >
> > > I'm wondering whether an alterative could be a function for splicing
> > > sequences such as lists and tuples which would avoid the need to create
> > > and then
On Thu, Mar 17, 2022 at 08:38:19AM -0400, Ricky Teachey wrote:
> Not a pro or con just an observation: since dictionaries are ordered now
> people would also (somewhat reasonably, imo) want to be able to splice
> them, too.
Dicts are not sequences. They might preserve insertion order, but that
i
On Thu, Mar 17, 2022, 5:23 AM Steven D'Aprano wrote:
On Thu, Mar 17, 2022 at 01:21:24AM +0900, Stephen J. Turnbull wrote:
> MRAB writes:
>
> > I'm wondering whether an alterative could be a function for splicing
> > sequences such as lists and tuples which would avoid the need to create
> > a
On 17/03/2022 05.21, Stephen J. Turnbull wrote:
> MRAB writes:
>
> > I'm wondering whether an alterative could be a function for splicing
> > sequences such as lists and tuples which would avoid the need to create
> > and then destroy intermediate sequences:
> >
> > splice(alist, i, 1
On Thu, Mar 17, 2022 at 01:21:24AM +0900, Stephen J. Turnbull wrote:
> MRAB writes:
>
> > I'm wondering whether an alterative could be a function for splicing
> > sequences such as lists and tuples which would avoid the need to create
> > and then destroy intermediate sequences:
> >
> >
MRAB writes:
> I'm wondering whether an alterative could be a function for splicing
> sequences such as lists and tuples which would avoid the need to create
> and then destroy intermediate sequences:
>
> splice(alist, i, 1 + 1, [value])
Does this make sense for lists? I don't see h
On Thu, 17 Mar 2022 at 01:09, Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
>
> > You can try putting an enhancement request on the bug tracker,
> > almost certainly you will be told to propose it here to see if
> > there is consensus that it is useful enough. You can submit a PR
> >
Steven D'Aprano writes:
> You can try putting an enhancement request on the bug tracker,
> almost certainly you will be told to propose it here to see if
> there is consensus that it is useful enough. You can submit a PR
> on the repo, but likewise. You can ask on Python-Dev, but you will
>
On 2022-03-15 23:13, Steven D'Aprano wrote:
On Tue, Mar 15, 2022 at 11:16:04AM +1100, Chris Angelico wrote:
> How do we make a new list with a change other than the same slice and
> concatenation we use with tuples?
>
> alist[:i] + [value] + alist[i+1:]
>
> I mean as an expression, of cours
On Mon, Mar 14, 2022 at 04:57:09PM +, wfdc via Python-ideas wrote:
> > You're going to have to work harder than that to convince me. It's
> > not clear how many of those examples are unique, and most are
> > concise and idiomatic.
>
> Ridiculous goalpost-moving. I literally just gave you
On Fri, Mar 11, 2022 at 06:26:52PM -0500, David Mertz, Ph.D. wrote:
> On Fri, Mar 11, 2022, 6:19 PM wfdc wrote:
>
> > > Likewise this which you wrote in another post: "Do you see why it's
> > useful to have immutability?"
> >
> > That's not insulting at all. It's a perfectly valid question to add
On Tue, Mar 15, 2022 at 10:04:45AM +1100, Chris Angelico wrote:
> Since a namedtuple *is* supposed to
> be both a sequence and a record, the names are part of the record
> interface, and the sequence is still part of that. Also, the field
> names don't have to be valid identifiers (although they u
On Tue, Mar 15, 2022 at 11:16:04AM +1100, Chris Angelico wrote:
> > How do we make a new list with a change other than the same slice and
> > concatenation we use with tuples?
> >
> > alist[:i] + [value] + alist[i+1:]
> >
> > I mean as an expression, of course we can split it over two statemen
On Mon, Mar 14, 2022 at 11:08:51PM -0400, David Mertz, Ph.D. wrote:
> On the other hand, looking through those examples in a cursory manner made
> me think about 75% of the time "why are they doing this silly approach?"
https://fs.blog/chestertons-fence/
Describing this as "silly" seems, well, s
> Those links were the first good faith comments I saw from OP.
What do you mean by that, exactly?
> looking through those examples in a cursory manner made me think about 75% of
> the time "why are they doing this silly approach?"
Give several examples.
--- Original Message ---
On Mon
On Mon, Mar 14, 2022, 7:52 PM Steven D'Aprano
> I got "No results matched your query" on the second URL, at which point I
> didn't bother with the first.
>
Hmm... while I don't support the proposal, I saw results at both links.
Those links were the first good faith comments I saw from OP.
A pret
On 2022-03-09 19:42, wfdc via Python-ideas wrote:
Add a "replace" method to tuples that returnsa new tuple with the element at a
given index replaced with a given value.
Hmm, no one appears to have mentioned DateTime.replace(). Did I miss it?
https://docs.python.org/3/library/datetime.h
On Tue, Mar 15, 2022 at 10:51:21AM +1100, Steven D'Aprano wrote:
> I got "No results matched your query" on the second URL, at which point
> I didn't bother with the first.
I tried again, with both URLs, and got plenty of hits this time.
Perhaps I had a copy-paste error with the URLs, or a tran
> I got "No results matched your query" on the second URL, at which point I
> didn't bother with the first.
Check again in case it's an error.
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29
On Mon, Mar 14, 2022 at 11:53:37AM -0700, Christopher Barker wrote:
> I don't think it should be added to mutable types -- there are already ways
> to do that, and there are any number of "make a new one with some change"
> methods that mutables don't have.
How do we make a new list with a change
On Mon, Mar 14, 2022 at 04:38:48PM +, wfdc wrote:
> > I would think that at least is obvious: the top voted Python
> > question on StackOverflow currently has 11891 votes. This is two
> > orders of magnitude less.
>
> Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159%
>
Again, you neglected to answer the question:
> what are the field names supposed to be if the datastructure is being treated
> as a sequence, of possibly arbitrary length?
> Since a namedtuple is supposed to be both a sequence and a record, the names
> are part of the record interface, and th
On Tue, 15 Mar 2022 at 10:02, wfdc via Python-ideas
wrote:
>
> See my previous response to Chris:
>
> > What are the named fields supposed to be if the datastructure is being
> > treated as a sequence? Indices again? Then what's the point of using
> > namedtuple rather than tuple in the first pl
> the OP has only had arguments like "namedtuples aren't sequences", which are
> not what I'd call compelling.
Why don't you answer the question I asked you?
--- Original Message ---
On Monday, March 14th, 2022 at 4:12 PM, Chris Angelico wrote:
> On Tue, 15 Mar 2022 at 05:37, Christop
See my previous response to Chris:
> What are the named fields supposed to be if the datastructure is being
> treated as a sequence? Indices again? Then what's the point of using
> namedtuple rather than tuple in the first place?
> And, by the way, field names must be valid identifiers.
> So a
On Mon, 14 Mar 2022 at 22:21, Greg Ewing wrote:
>
> On 15/03/22 6:14 am, wfdc via Python-ideas wrote:
> > The whole *point* is that namedtuples let you use *named fields* rather
> > than indices. That's the point. That's the purpose.
>
> I would say the point of namedtuple is to let you use eithe
On 15/03/22 6:14 am, wfdc via Python-ideas wrote:
The whole *point* is that namedtuples let you use *named fields* rather than
indices. That's the point. That's the purpose.
I would say the point of namedtuple is to let you use either field
names or indices, whichever makes the most sense for
On Tue, 15 Mar 2022 at 05:37, Christopher Barker wrote:
>
> > there has STILL been no answer to the questions of "why not
>>
>> use namedtuple" and "why not use a dataclass",
>
>
> The OP may not have, but I at least answered why not namedtuple? very early
> in the thread
>
> Chris A: sorry to ca
On Mon, Mar 14, 2022 at 11:16 AM wfdc via Python-ideas <
python-ideas@python.org> wrote:
> jax is another example that uses the name 'set' for this functionality:
>
> https://jax.readthedocs.io/en/latest/jax.numpy.html
set() strikes me as a better name for a mutating operation. Apparently Jax
ar
> there has STILL been no answer to the questions of "why not
> use namedtuple" and "why not use a dataclass",
The OP may not have, but I at least answered why not namedtuple? very early
in the thread. the TL;DR: there are use cases for namedtuple, but if the
only reason you would choose a named
jax is another example that uses the name 'set' for this functionality:
https://jax.readthedocs.io/en/latest/jax.numpy.html
On second thought, perhaps it wouldn't be a bad idea to extend this proposal to
built-in sequence types in general (list, str, tuple, and bytes).
Examples of this function
And, by the way, field names must be valid identifiers.
So again, what are the field names supposed to be if the datastructure is being
treated as a sequence, of possibly arbitrary length?
--- Original Message ---
On Monday, March 14th, 2022 at 1:07 PM, Chris Angelico wrote:
> On Tue,
The whole *point* is that namedtuples let you use *named fields* rather than
indices. That's the point. That's the purpose.
What are the named fields supposed to be if the datastructure is being treated
as a sequence? Indices again? Then what's the point of using namedtuple rather
than tuple in
On Tue, 15 Mar 2022 at 04:02, wfdc wrote:
>
> > A namedtuple IS a sequence. It is a tuple. They are deliberately designed
> > to be drop-in replacements for tuples.
>
> I meant that they're not meant to be addressed as sequences. That's the whole
> point of namedtuple: to avoid doing that.
>
Th
> A namedtuple IS a sequence. It is a tuple. They are deliberately designed to
> be drop-in replacements for tuples.
I meant that they're not meant to be addressed as sequences. That's the whole
point of namedtuple: to avoid doing that.
And the first point still applies.
--- Original Messa
> You're going to have to work harder than that to convince me. It's not clear
> how many of those examples are unique, and most are concise and idiomatic.
Ridiculous goalpost-moving. I literally just gave you 1000+ examples of this
functionality being used, which is what you asked for, includi
> there has STILL been no answer to the questions of "why not use namedtuple"
> and "why not use a dataclass"
Christopher addressed that a long time ago.
> no sample code provided
See
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs
See
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp
https://sourc
> wfdc (should we call you something which is not a random-looking string of
> consonants?)
wfdc is fine.
> it might help if you could give examples of this functionality from other
> languages or classes. What do they call the method?
https://clojuredocs.org/clojure.core/assoc
https://immuta
> I would think that at least is obvious: the top voted Python question on
> StackOverflow currently has 11891 votes. This is two orders of magnitude less.
Like I said, this puts it in the top 3031 / 1908740 = 0.00159 = 0.159% of
Python questions by vote count.
That's not "a low number of votes
On Tue, 15 Mar 2022 at 03:16, wfdc wrote:
> > Yes, and dataclasses and namedtuples support this concept very nicely. You
> > still haven't shown why neither works.
>
> 1. They're less efficient, as Christopher pointed out long ago.
>
> 2. They're not sequences, so conceptually the wrong tool for
You may not, but others do. See
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patte
See
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp
and
https://
Hi,
You are clearly not making progress, and this list is no longer useful
to you for this idea -- you know what you want, it's easy enough to
implement, and you don't need our advice for that I assume.
I suggest you give up on this list, write the code, make sure it's
well-documented, and submit
On Mon, 14 Mar 2022 at 23:54, Christopher Barker wrote:
>
> Wow!
>
> Does anyone else see the irony in the fact that just a couple days ago, Chris
> A lamented that Python-ideas seemed to
> Immediately reject any new idea out of hand? And yes, Chris, you have joined
> in the piling on in this ca
On 11/03/2022 02:19, wfdc wrote:
> This could cause confusion because str.replace() has a completely different
API.
We're talking about tuples here, not strings.
Yes, I know, and tuples and strings are different. But *humans* can be
confused by "replace" having a totally different API in di
Wow!
Does anyone else see the irony in the fact that just a couple days ago,
Chris A lamented that Python-ideas seemed to
Immediately reject any new idea out of hand? And yes, Chris, you have
joined in the piling on in this case.
I didn’t think it was that bad, but this thread has been pretty pai
Just to add, the following Sourcegraph queries provide good evidence of
widespread use of this functionality:
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%
See also the following Sourcegraph query for examples of use of the second
approach:
https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw
On 11/03/2022 19:30, wfdc wrote:
> I could (I believe) write "count" as an (inefficient) 1-liner, but not "index". I suggest it's harder than
you think. (Try it!)
How much harder? Can you post your candidate?
It was you that said it could be a 1-liner. The burden of proof is on
you, if yo
See
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp
and
https://
See the following Sourcegraph query for examples of use of this pattern:
https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%2
Now read what you said earlier:
> So it appears the "problem" this is intended to solve is "Python isn't
> Haskell."
> But Haskell exists, and this is a non-problem looking for a solution.
A bizarre incongruence, right?
--- Original Message ---
On Friday, March 11th, 2022 at 6:26 PM, D
Travel Portal Development
We have a devoted group of engineers bringing unparalleled experience and
information to the table for the clients, a one of a kind travel gateway that
will certainly speed up the brand or business.
https://www.flightapis.com/travel-portal-development
__
On 11/03/2022 21:33, wfdc wrote:
How about something like
def index(self, x):
return next(i for i, a in enumerate(self) if a == x)
Including start and end:
def index(self, x, start=0, end=-1):
return next(i for i, a in tuple(enumerate(self))[start:end] if a == x)
No cigar. If the el
On Fri, Mar 11, 2022 at 01:38:57AM +, Rob Cliffe via Python-ideas wrote:
> This could cause confusion because str.replace() has a completely
> different API.
The old "painter.draw()" versus "gun_slinger.draw()" problem.
It does exist, but it's not generally a *major* problem.
> And indeed
On Fri, Mar 11, 2022, 6:19 PM wfdc wrote:
> > Likewise this which you wrote in another post: "Do you see why it's
> useful to have immutability?"
>
> That's not insulting at all. It's a perfectly valid question to address to
> a post that seems to be contesting the purpose of immutable types in t
On 2022-03-11 12:03, wfdc via Python-ideas wrote:
I've used Python for 23+ years now. I've had occasion where I'd use this
methods maybe in the low-tens of times.
I'd call the purpose rare at best.
This comment is useless without a base rate. What's the base rate for
comparable methods that *a
Game theorist here.
wfdc via Python-ideas writes:
> Do you see why it's useful to have immutability?
Sure, it's potentially hashable. But I can't recall ever finding that
useful in working with matrix games (loosely speaking, I mean games
with a finite set of players, each with a finite strate
> they may have to spend time patiently arguing for it, answering objections,
> demonstrating use cases, covering corner cases, discussing
> alternatives/variations etc.
That's what I'm doing.
A direct writing style does not mean "belligerent".
> But it seems to me that something you can imple
Please. If we're now talking about specific exceptions, my replace isn't a
one-liner either. I was clearly referring to actual functionality.
If you want that specific exception, 2 lines are sufficient.
--- Original Message ---
On Friday, March 11th, 2022 at 4:45 PM, Rob Cliffe
wrote:
On Fri, Mar 11, 2022 at 07:12:49PM +, wfdc via Python-ideas wrote:
> > one Stack Overflow question, with a low number of votes
>
> Mind explaining why you say 159 is a "low number of votes" for a
> StackOverflow question on Python?
I would think that at least is obvious: the top voted Pytho
On Sat, 12 Mar 2022 at 07:38, wfdc wrote:
>
> > you haven't shown us what your use-case actually is
>
> Any use-case where you'd want to modify an entry of an immutable sequence.
That doesn't answer the question any more than your original code
does. You're still starting with the assumption that
This is a common scenario on python-list or python-ideas:
Someone has an idea that they think is the greatest thing since sliced
bread. They propose it, and feel hurt / rejected when they get pushback
instead of everyone jumping up and down and saying how brilliant it is.
Sometimes they are do
On Sat, 12 Mar 2022 at 08:53, wfdc via Python-ideas
wrote:
>
> So do you propose getting rid of the tuple type entirely or not?
>
> Do you see why it's useful to have immutability?
>
Immutability is extremely useful. I use tuples VERY frequently. But I
don't then need to replace one element in th
So do you propose getting rid of the tuple type entirely or not?
Do you see why it's useful to have immutability?
--- Original Message ---
On Friday, March 11th, 2022 at 4:47 PM, David Mertz, Ph.D.
wrote:
> Yes. To be clear, immutability isn't a use case, it's a particular technique
>
Yes. To be clear, immutability isn't a use case, it's a particular
technique that can be useful for solving some problems.
This is probably a clear enough example of the XY-problem as to be worth
adding to the Wikipedia article on that topic.
We sometimes see other similar proposals to e.g. "solv
(To be clear, I'm saying David Mertz's proposal fails the immutability
criterion, not Christopher Barker's.)
--- Original Message ---
On Friday, March 11th, 2022 at 4:39 PM, wfdc wrote:
> Don't yell.
>
> You just effectively re-implemented Christopher Barker's solution (which was
> als
Wrong.
If you're not willing to make substantive contributions to this thread, I
suggest you refrain from posting further.
--- Original Message ---
On Friday, March 11th, 2022 at 4:42 PM, David Mertz, Ph.D.
wrote:
> So it appears the "problem" this is intended to solve is "Python isn'
So it appears the "problem" this is intended to solve is "Python isn't
Haskell."
But Haskell exists, and this is a non-problem looking for a solution.
On Fri, Mar 11, 2022, 4:39 PM wfdc wrote:
> Don't yell.
>
> You just effectively re-implemented Christopher Barker's solution (which
> was also
Don't yell.
You just effectively re-implemented Christopher Barker's solution (which was
also present in the StackOverflow thread), with the downside that it fails the
immutability criterion.
Saying "just be careful not to mutate the original datastructure" isn't a
solution. There's a reason w
How about something like
def index(self, x):
return next(i for i, a in enumerate(self) if a == x)
Including start and end:
def index(self, x, start=0, end=-1):
return next(i for i, a in tuple(enumerate(self))[start:end] if a == x)
--- Original Message ---
On Friday, March 11th, 2022 at
On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas
wrote:
> > why haven't you used a list
> 2. I don't want to modify the original sequence.
>
There's a really easy solution for you that will even be more perfomant.
Use a list and DON'T modify the original!
This is ABSOLUTELY an XY-problem...
> why haven't you used a list
1. A list is not immutable.
2. I don't want to modify the original sequence.
--- Original Message ---
On Friday, March 11th, 2022 at 4:07 PM, Marco Sulla
wrote:
> On Fri, 11 Mar 2022 at 21:39, wfdc via Python-ideas
>
> python-ideas@python.org wrote:
>
>
> you haven't shown us what your use-case actually is
Any use-case where you'd want to modify an entry of an immutable sequence.
Modifying an immutable datastructure is not a contradictory statement. In fact,
there's a whole literature on it. See
https://en.wikipedia.org/wiki/Purely_functional_d
> the "not every one-line function needs to be a builtin" principle applies
> here, in my view.
The "not every one-line function needs to *not* be a builtin" principle cancels
it out.
And the "frequently-used functionality should be built-in" (Python's "batteries
included" philosophy) override
> I've used Python for 23+ years now. I've had occasion where I'd use this
> methods maybe in the low-tens of times.
> I'd call the purpose rare at best.
This comment is useless without a base rate. What's the base rate for
comparable methods that *are* part of the standard library, like index a
On Sat, 12 Mar 2022 at 06:50, wfdc wrote:
>
> > You still haven't shown why a namedtuple is wrong for your use-case.
>
> See Christopher Barker's previous reply to you.
>
> Furthermore, namedtuples have *fieldnames*. Tuples have *indices*. Tuples are
> conceptually more appropriate if we're deali
On Fri, 11 Mar 2022 at 19:12, wfdc wrote:
> What kind of evidence would satisfy you? And how did previous proposals you
> supported obtain such evidence?
Honestly, probably nothing. I don't think this is a good idea in any
case, the "not every one-line function needs to be a builtin"
principle a
> You still haven't shown why a namedtuple is wrong for your use-case.
See Christopher Barker's previous reply to you.
Furthermore, namedtuples have *fieldnames*. Tuples have *indices*. Tuples are
conceptually more appropriate if we're dealing with what are supposed to be
numeric indices into s
On Fri, Mar 11, 2022, 2:39 PM wfdc wrote:
> > Not every one line function needs to be a method on a built-in type.
>
> Not every one line function needs to *not* be a method on a built-in type.
> See tuple's count method for an example.
>
Again, if users find themselves re-implementing the same u
> Not every one line function needs to be a method on a built-in type.
Not every one line function needs to *not* be a method on a built-in type. See
tuple's count method for an example.
Again, if users find themselves re-implementing the same utility function over
and over again across differe
On Sat, 12 Mar 2022 at 06:33, wfdc via Python-ideas
wrote:
>
> > But *humans* can be confused by "replace" having a totally different API in
> > different contexts.
>
> I doubt that's the case here.
>
> The closest equivalent to tuple's .replace method would be namedtuple's
> _.replace method, w
> But *humans* can be confused by "replace" having a totally different API in
> different contexts.
I doubt that's the case here.
The closest equivalent to tuple's .replace method would be namedtuple's
_.replace method, which also has a different API from string's .replace method.
> I could (I
-1
Not every one line function needs to be a method on a built-in type.
I like that tuples have extremely limited methods. Following the iterable
protocol seems fine (also indexable).
If I were forced to endorse one new method for tuples, I doubt `.replace()`
would be in my top five consideratio
> one Stack Overflow question, with a low number of votes
Mind explaining why you say 159 is a "low number of votes" for a StackOverflow
question on Python?
According to https://stackoverflow.com/questions/tagged/python, this puts it in
the top 3031 / 1908740 = 0.00159 = 0.159% of Python questi
On Fri, 11 Mar 2022 at 02:20, wfdc via Python-ideas
wrote:
> If users find themselves re-implementing the same utility function over again
> and over again across different projects, it's a good sign that such a
> function should be part of the standard library.
And yet you haven't demonstrate
>
>
> > On the other hand, it might be an indication that a tuple is the wrong
> tool for the job.
>
maybe -- if I"m doing a lot of replacing, I likely would turn to a list --
but if you need an immutable, you need an immutable. I'm pretty sure I've
written code like:
temp = list(a_tuple)
temp[i]
I'm pretty wary of adding methods to builtins -- I wonder how often tuples
are either subclassed or duck-typed if the answer isn't "virtually never",
then it's a problem to add to the API.
That being said, I do find myself wanting to change just one element of a
tuple pretty frequently, and it alw
> On the other hand, it might be an indication that a tuple is the wrong tool
> for the job.
1. It's not. The original tuple is not being mutated. And it may be desirable
to enforce that immutability at the type level. Hence the choice of tuple
rather than, say, list.
2. The same "objection" w
On Fri, 11 Mar 2022 at 14:36, Jeremiah Vivian
wrote:
> > See Python's "batteries included" philosophy.
> > If users find themselves re-implementing the same utility function over
> > again and over again across different projects, it's a good sign that such
> > a function should be part of the s
> We're talking about tuples here, not strings.
>
> Saying that a method's API differs for a completely different type,
> especially when such a difference would be expected given the difference in
> types, is not a valid objection.
I agree with this. It was also earlier specified:
> Furthermore,
> This could cause confusion because str.replace() has a completely different
> API.
We're talking about tuples here, not strings.
Saying that a method's API differs for a completely different type, especially
when such a difference would be expected given the difference in types, is not
a val
This could cause confusion because str.replace() has a completely
different API.
And indeed if a replace method were added to tuples, a fair case could
be made for it having the same API, viz.
replace(old, new, count=-1)
Whereas your suggestion can be written as a simple 1-liner, as you
dem
94 matches
Mail list logo
