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
Ok, thank you. I will make the issue and pull request once the switch to GitHub
issues is done.
On Sun, Mar 6, 2022, at 10:20 AM, Eric V. Smith wrote:
>
>> On Mar 6, 2022, at 5:05 AM, Barry Scott wrote:
>>
>>
>>> On 6 Mar 2022, at 07:19, t...@tomforb.es wrote:
>>>
>>> For reference, this re
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
23 matches
Mail list logo
