Oops, look like I took this off-list by accident -- bringing it back on.
On Fri, Aug 28, 2020 at 12:50 PM Guido van Rossum wrote:
> IMO the bar for attempting to solve this is pretty high, since I can think
> of no way to solve it without breaking old code that doesn't involve
> introducing new
Em qui, 27 de ago de 2020 10:37, M.-A. Lemburg escreveu:
> On 27.08.2020 15:17, Alex Hall wrote:
> > On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote:
> >
> >> I disagree on the above assessment. I have had such a get() builtin
> >> in mxTools for more than 20 years now and found that I
Thanks for the comments! Some food for thought. One comment:
Paul Moore writes:
> On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull
> wrote:
> > True, but not really fair under my assumption that `x[i, default=d]`
> > becomes the accepted way of doing it generally. dict.get would be a
>
On 29/08/20 12:06 am, David Mertz wrote:
I only thought of it because `mydict[foo=bar]` now raises a
SyntaxError, so raising something different would technically be a
change in behavior.
It's going to be a change in behaviour whatever you raise,
because it's currently a compile time error.
On 2020-08-28 at 08:41:04 -0400,
Regarding "[Python-ideas] Re: What about having a .get(index, default) method
for arrays like we have for dicts?,"
Richard Damon wrote:
> On 8/28/20 8:24 AM, David Mertz wrote:
> >
> > As a side note, I don't really get why everyone else thinks a
> > try/except
On Fri, 28 Aug 2020 at 13:26, David Mertz wrote:
> As a side note, I don't really get why everyone else thinks a try/except is
> the most natural approach while a ternary seems more obvious to me for this
> situation. But it kinda connects to me liking list.get() better, I think...
> since
On 8/28/20 8:24 AM, David Mertz wrote:
>
> As a side note, I don't really get why everyone else thinks a
> try/except is the most natural approach while a ternary seems more
> obvious to me for this situation. But it kinda connects to me liking
> list.get() better, I think... since "not enough
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > > Suppose we didn't have dict.get(). I would then probably write:
> > > val = mydict[key] if key in mydict else None
> > >
> > > Likewise, since we don't have list.get(), I would write:
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > tuple, or dict themselves. So `mylist[99, default=4]` would still
> > be a syntax error (or maybe a different exception).
>
> I don't think it can be a SyntaxError because you can't always
On Fri, Aug 28, 2020 at 05:30:26PM +0900, Stephen J. Turnbull wrote:
> David Mertz writes:
>
> > I support named indices. But I strongly oppose using them in list,
> > tuple, or dict themselves. So `mylist[99, default=4]` would still
> > be a syntax error (or maybe a different exception).
>
On 28.08.2020 10:30, Stephen J. Turnbull wrote:
> M.-A. Lemburg writes:
> > On 27.08.2020 17:53, David Mertz wrote:
>
> > > Suppose we didn't have dict.get(). I would then probably write:
> > >
> > > val = mydict[key] if key in mydict else None
> > >
> > > Likewise, since we don't
On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
>
> > Furthermore, I'd be very, very strongly opposed to having x[i,
> > default=d] be a way of supplying a default result if i isn't present
> > in *any* subscriptable class, and particularly in dict as an
> >
M.-A. Lemburg writes:
> On 27.08.2020 17:53, David Mertz wrote:
> > Suppose we didn't have dict.get(). I would then probably write:
> >
> > val = mydict[key] if key in mydict else None
> >
> > Likewise, since we don't have list.get(), I would write:
> >
> > val = mylist[N] if
Alex Hall writes:
> Do you not usually refactor duplicated code?
Taking "you" as generic: it depends.
> What *do* you refactor?
Code is expressive. In cases where the duplication results in
equivalent objects, I habitually refactor. When the process is
important to express and the
David Mertz writes:
> I support named indices. But I strongly oppose using them in list,
> tuple, or dict themselves. So `mylist[99, default=4]` would still
> be a syntax error (or maybe a different exception).
I don't think it can be a SyntaxError because you can't always know
that mylist
On Thu, Aug 27, 2020 at 07:10:38PM +0200, Alex Hall wrote:
> On Thu, Aug 27, 2020 at 6:32 PM Steven D'Aprano wrote:
>
> > Personally, I found your examples underwhelming because they're mostly
> > repetitions of the same pattern.
> >
>
> That's surprising to me. When I see the same pattern over
On Thu, Aug 27, 2020 at 2:27 PM Ricky Teachey wrote:
>
> On Thu, Aug 27, 2020 at 2:14 PM Christopher Barker
> wrote:
>
>> On Thu, Aug 27, 2020 at 11:01 AM Ricky Teachey wrote:
>>
>>> What about something like this:
> class Name(NamedTuple):
> first: str
> last:
On Thu, Aug 27, 2020 at 2:14 PM Christopher Barker
wrote:
> On Thu, Aug 27, 2020 at 11:01 AM Ricky Teachey wrote:
>
>> What about something like this:
>>>
>>>
class Name(NamedTuple):
first: str
last: str
d = NamedKeyDict(Named)
d[first='david',
On Thu, Aug 27, 2020 at 11:01 AM Ricky Teachey wrote:
> What about something like this:
>>
>>
>>> class Name(NamedTuple):
>>> first: str
>>> last: str
>>>
>>> d = NamedKeyDict(Named)
>>> d[first='david', last='mertz'] = 1_000_000 # dollars
>>>
>>
right -- that would be a new custom
On Thu, Aug 27, 2020 at 10:24 AM David Mertz wrote:
> On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
>
>> I agree -- this is very much a feature for third party packages -- or
>> *maybe* some future stdlib class, but the builtins are fine as they are.
>>
>> In fact, I don't think there's a
On Thu, Aug 27, 2020 at 1:45 PM David Mertz wrote:
> On Thu, Aug 27, 2020, 1:35 PM Ricky Teachey
>
>> Conceptually, an "immutable collection" serves a different purpose than
>>> "a collection of axes", even if they work then same under the hood.
>>>
>>
>> What about something like this:
>>
>>
On Thu, Aug 27, 2020, 1:35 PM Ricky Teachey
> Conceptually, an "immutable collection" serves a different purpose than "a
>> collection of axes", even if they work then same under the hood.
>>
>
> What about something like this:
>
> class Name(NamedTuple):
> first: str
> last: str
>
> d =
On Thu, Aug 27, 2020 at 1:29 PM David Mertz wrote:
> On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
>
>> I agree -- this is very much a feature for third party packages -- or
>> *maybe* some future stdlib class, but the builtins are fine as they are.
>>
>> In fact, I don't think there's a
On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
> I agree -- this is very much a feature for third party packages -- or
> *maybe* some future stdlib class, but the builtins are fine as they are.
>
> In fact, I don't think there's a single use of a tuple of indexes (meaning
> something other than
On Thu, Aug 27, 2020 at 8:24 AM David Mertz wrote:
> I support named indices. But I strongly oppose using them in list,
tuple, or dict themselves. So `mylist[99, default=4]` would still be a
syntax error (or maybe a different exception).
I agree -- this is very much a feature for third party
On Thu, Aug 27, 2020 at 6:32 PM Steven D'Aprano wrote:
> Personally, I found your examples underwhelming because they're mostly
> repetitions of the same pattern.
>
That's surprising to me. When I see the same pattern over and over that's
when I most want to refactor into a common
On Thu, Aug 27, 2020 at 03:17:24PM +0200, Alex Hall wrote:
> I'm copying my earlier post because apparently linking to it repeatedly has
> no effect and people keep on claiming that this method wouldn't be useful
> while not saying a word about the evidence I presented that it would be.
Perhaps
On 27.08.2020 17:53, David Mertz wrote:
> On Thu, Aug 27, 2020 at 11:37 AM M.-A. Lemburg wrote:
>
>> Asking a dict d of potentially any number of items for
>> existence of a particular item x is somewhat different than asking
>> a list l of a certain length i for the item at position i+1.
>>
>
On Thu, Aug 27, 2020 at 11:49:22PM +0900, Stephen J. Turnbull wrote:
> Alex Hall writes:
>
> > OK, I'll try again. Do people want collections to get a standard 'default'
> > for `__getitem__`?
>
> I don't know.
I'm pretty sure that Guido said that he doesn't want the builtin dict
and list
On Thu, Aug 27, 2020 at 11:37 AM M.-A. Lemburg wrote:
> Asking a dict d of potentially any number of items for
> existence of a particular item x is somewhat different than asking
> a list l of a certain length i for the item at position i+1.
>
Suppose we didn't have dict.get(). I would then
On Thu, 27 Aug 2020 at 16:21, David Mertz wrote:
>
> On Thu, Aug 27, 2020 at 10:51 AM Stephen J. Turnbull
> wrote:
>>
>> They're going to get one, is my reading of the "named indicies"
>> thread. That is, it looks to me very likely that index notation
>> (`x[i]`) is going to support keyword
On 27.08.2020 16:01, Alex Hall wrote:
> On Thu, Aug 27, 2020 at 3:37 PM M.-A. Lemburg wrote:
>
>> If I'm not mistaken, all those listed cases fall under the second case
>> I mentioned (branching on length).
>>
>> If your API allows for optional list entries, then it's better to
>> branch on
On Thu, Aug 27, 2020 at 10:51 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> They're going to get one, is my reading of the "named indicies"
> thread. That is, it looks to me very likely that index notation
> (`x[i]`) is going to support keyword arguments (`x[i, k=v]`).
Alex Hall writes:
> OK, I'll try again. Do people want collections to get a standard 'default'
> for `__getitem__`?
I don't know.
> I don't want mappings to grow a second way to do the same thing,
They're going to get one, is my reading of the "named indicies"
thread. That is, it looks
On Thu, Aug 27, 2020 at 3:37 PM M.-A. Lemburg wrote:
> If I'm not mistaken, all those listed cases fall under the second case
> I mentioned (branching on length).
>
> If your API allows for optional list entries, then it's better to
> branch on length (e.g. as in the pytest case). If this
On 27.08.2020 15:17, Alex Hall wrote:
> On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote:
>
>> I disagree on the above assessment. I have had such a get() builtin
>> in mxTools for more than 20 years now and found that I hardly ever
>> used it:
>>
>>
Em qui, 27 de ago de 2020 10:09, M.-A. Lemburg escreveu:
> On 27.08.2020 14:40, Daniel. wrote:
> > It's simple:
> >
> > def get(self, i, default=None):
> > try:
> > return self[i]
> > except IndexError:
> > return default
> >
> > That was the idea, just a safe wrapper
On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote:
> I disagree on the above assessment. I have had such a get() builtin
> in mxTools for more than 20 years now and found that I hardly ever
> used it:
>
> https://www.egenix.com/products/python/mxBase/mxTools/doc/#_Toc293606201
>
> The reason
On Thu, Aug 27, 2020 at 11:13 PM M.-A. Lemburg wrote:
> For those cases, where a list can have a variable
> number of entries (e.g. optional arguments, file lists, etc.),
> code should clearly branch on list length and then determine the
> right strategy to fetch items.
Pattern matching seems
On 27.08.2020 14:40, Daniel. wrote:
> It's simple:
>
> def get(self, i, default=None):
> try:
> return self[i]
> except IndexError:
> return default
>
> That was the idea, just a safe wrapper arround IndexError. Because it's very
> common to need to catch this. I posted
An .get method wont hurt duck typing, it makes it better. Also most of the
time we're working with plain dicts and lists not abtract classes.
If you're typechecking for a Sequence you cant treat it as a list, and this
is already true because there are methods in list that dont exists Sequence
as
On Thu, Aug 27, 2020 at 10:15 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Alex Hall writes:
> > On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull <
> > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> >
> > > If the "keyword arguments in __getitem__" feature is
Alex Hall writes:
> On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> > If the "keyword arguments in __getitem__" feature is added, .get() is
> > purely redundant. (Of course this thread would then become "make
> > 'default' a standard
Oh thanks, I had no idea that existed.
I wanted to experiment with Mapping and unions but it's not working. I
couldn't find any existing issues about this. Should I be opening an issue?
If not then there's no need to explain what I'm doing wrong.
```
$ cat test.py
print({} | {})
$ ./python
Use typing.AbstractSet for the ABC (there was an unfortunate naming
conflict -- we have dict and Mapping, list and Sequence, but set and Set...)
On Wed, Aug 26, 2020 at 2:16 PM Alex Hall wrote:
> On Wed, Aug 26, 2020 at 10:10 PM Christopher Barker
> wrote:
>
>> Honestly, I haven't delved into
On Wed, Aug 26, 2020 at 10:10 PM Christopher Barker
wrote:
> Honestly, I haven't delved into type checking much, so maybe I'm making
> this up, but what if you write a function that is type hinted to take a
> Mapping, and uses | or |=, and all the test code uses a built in dict, and
> all seems
I’m sorry, I just can’t teach you how static type checking works. Read the
mypy docs, install it, and experiment.
On Wed, Aug 26, 2020 at 13:10 Christopher Barker
wrote:
> On Wed, Aug 26, 2020 at 12:38 PM Alex Hall wrote:
>
>>
>> This is why we have ABCs in the first place (and static
On Wed, Aug 26, 2020 at 12:38 PM Alex Hall wrote:
>
> This is why we have ABCs in the first place (and static checking). So that
> you can't add it to Sequence is already a smell. If it's in the Mapping
> protocol, why isn't it in the Sequence protocol?
>
> This is all just a general feature of
On Wed, Aug 26, 2020 at 7:56 PM Guido van Rossum wrote:
> On Wed, Aug 26, 2020 at 10:45 AM Alex Hall wrote:
>
>> On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum
>> wrote:
>>
>>> But for your convenience you are proposing a problematic change (see
>>> posts by others).
>>>
>>
>> I think we've
On Wed, Aug 26, 2020 at 10:45 AM Alex Hall wrote:
> On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum wrote:
>
>> But for your convenience you are proposing a problematic change (see
>> posts by others).
>>
>
> I think we've established it's problematic to add it to the Sequence ABC,
> but in
I think this method would be useful for list itself (maybe tuple, but I
care less about that). It certainly should not be part of the Sequence
protocol.
I have often programmed a pattern where I .append() elements to a list in a
loop, and *expect* at least N things to make it in. In such case,
On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum wrote:
> But for your convenience you are proposing a problematic change (see posts
> by others).
>
I think we've established it's problematic to add it to the Sequence ABC,
but in terms of only adding it to specific sequences like lists, I don't
But for your convenience you are proposing a problematic change (see posts
by others). Maybe I meant overgeneralization instead.
On Wed, Aug 26, 2020 at 10:20 AM Alex Hall wrote:
> On Wed, Aug 26, 2020 at 4:32 PM Guido van Rossum wrote:
>
>> FWIW I don’t think we should add a .get() method for
On Wed, Aug 26, 2020 at 4:32 PM Guido van Rossum wrote:
> FWIW I don’t think we should add a .get() method for Sequence or for list.
> It reeks of hyper-correctness.
>
What do you mean by this? I want the method because it's useful and
convenient, not because it's 'correct'. I don't think that
Yes. That's what I meant by "the mixins are part of the contract", sorry.
On Wed, Aug 26, 2020 at 8:45 AM Greg Ewing
wrote:
> On 27/08/20 2:32 am, Guido van Rossum wrote:
> > The mixins are part of the contract. You are free to override them,
> > their implementation is just a helpful,default.
On 27/08/20 2:32 am, Guido van Rossum wrote:
The mixins are part of the contract. You are free to override them,
their implementation is just a helpful,default.
That doesn't really answer my question. To put it another way:
If someone wanted to implement an object that obeys the mapping
On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> If the "keyword arguments in __getitem__" feature is added, .get() is
> purely redundant. (Of course this thread would then become "make
> 'default' a standard keyword argument for mutable
Alex Hall writes:
> I can't see any reason not to add it to range, strings, bytes,
> deque, array, etc. beyond implementation effort. I also think it's
> fine to leave them out at first.
If the "keyword arguments in __getitem__" feature is added, .get() is
purely redundant. (Of course this
The mixins are part of the contract. You are free to override them, their
implementation is just a helpful,default.
FWIW I don’t think we should add a .get() method for Sequence or for list.
It reeks of hyper-correctness.
On Wed, Aug 26, 2020 at 01:33 Alex Hall wrote:
> On Wed, Aug 26, 2020 at
On Wed, Aug 26, 2020 at 1:41 AM Steven D'Aprano wrote:
> On Tue, Aug 25, 2020 at 10:22:20AM -0700, Christopher Barker wrote:
>
> > This one is easier than most because it's pretty much a do we or don't we
> > question, with the spelling semantics, all pretty much already decided.
>
> Is it to be
On Wed, Aug 26, 2020 at 1:47 AM Greg Ewing
wrote:
> As a point of interest, is get() considered an official part of the
> mapping protocol, or just nice-to-have?
>
> The docs don't seem to be very clear about that. There used to be
> some tables listing the methods making up the core sequence
As a point of interest, is get() considered an official part of the
mapping protocol, or just nice-to-have?
The docs don't seem to be very clear about that. There used to be
some tables listing the methods making up the core sequence and
mapping protocols, but I can't find them now. Have they
On Tue, Aug 25, 2020 at 10:22:20AM -0700, Christopher Barker wrote:
> This one is easier than most because it's pretty much a do we or don't we
> question, with the spelling semantics, all pretty much already decided.
Is it to be added to lists, or lists and tuples? How about range
objects?
On Tue, Aug 25, 2020 at 10:51 AM Alex Hall wrote:
> On Tue, Aug 25, 2020 at 7:23 PM Christopher Barker
>
I think if it's a potential problem to add it to the ABC then let's just
> defer that and only add it to the built in sequences.
>
Well yes, that’s a fine solution. Though an advantage of
On Tue, Aug 25, 2020 at 7:23 PM Christopher Barker
wrote:
> Though I haven't quite seen it said explicitly -- is this proposed to be
> added to the Sequence ABC?
>
> If so, there is a potential problem -- the ABC's "namespace" is not
> reserved, so if you add .get(), then any code out in the
On Tue, Aug 25, 2020 at 5:50 AM Alex Hall wrote:
> I think that the discussion here simply fizzled away because:
>
> 1. People got distracted by talking about PEP 505 which really isn't very
> relevant and would solve a different problem.
> 2. There are no major objections, so there isn't much
Oh, thanks :)
Anyway, it still applies for fetching a single arbitrary indexes
Em ter., 25 de ago. de 2020 às 11:07, Alex Hall
escreveu:
> I mean you could write these as:
>
> if stack[-3:] == [x, y, z]
>
> and
>
> elif stack[-1:] == [t]
>
> But plenty of use cases still exist (
>
On 2020-08-25 13:52, Daniel. wrote:
I just came across this again while implementing an parser
I would like to compare stack elements as
if stack[-3] == x and stack[-2] == y and stack[-1] == z
if stack[-3 : ] == [x, y, z]:
and somewere below
elif stack[-1] == t
elif stack[-1 : ] == [t]:
I mean you could write these as:
if stack[-3:] == [x, y, z]
and
elif stack[-1:] == [t]
But plenty of use cases still exist (
https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/)
and I think we shouldn't need to keep talking about
Here is one example added in stdlib
https://github.com/python/cpython/pull/14813/files
It's checking the truthness of value before calling value[0], this is a
perfect match for value.get(0)
Here is another, just the same use case,
https://github.com/python/cpython/pull/17515/files
When you
I just came across this again while implementing an parser
I would like to compare stack elements as
if stack[-3] == x and stack[-2] == y and stack[-1] == z
and somewere below
elif stack[-1] == t
I had to spread `len(stack)` in a lot of places.
People said about the length of a list is
On Thu, Jul 2, 2020 at 10:33 PM Alex Hall wrote:
> On the other hand, `list.get` seems very doable to me. It's not new
> syntax. It would be extremely easy to learn for anyone familiar with
> `dict.get`, which is pretty much essential knowledge. You'd probably have
> some people guessing it
Em sex, 3 de jul de 2020 11:37, Kyle Lahnakoski
escreveu:
>
> On 2020-06-27 09:34, Daniel. wrote:
> > When I need to traverse nested dicts, is a common pattern to do
> >
> > somedict.get('foo', {}).get('bar', {})
> >
> > But there is no such equivalent for arrays, wouldn't be nice if we can
> >
On 2020-06-27 09:34, Daniel. wrote:
When I need to traverse nested dicts, is a common pattern to do
somedict.get('foo', {}).get('bar', {})
But there is no such equivalent for arrays, wouldn't be nice if we can
follow
somedict.get('foo', {}).get('bar', []).get(10) ... ?
What do you think?
On Fri, Jul 3, 2020 at 5:36 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Alex Hall writes:
>
> > `dct.get('foo')?.get(0)?.get('bar')`.
> >
> > I would quite like to have PEP 505, but I don't know how to revive it.
> And
> > I'm not surprised that it's deferred,
Alex Hall writes:
> `dct.get('foo')?.get(0)?.get('bar')`.
>
> I would quite like to have PEP 505, but I don't know how to revive it. And
> I'm not surprised that it's deferred, there's generally reluctance to add
> new syntax, especially symbols.
Bottom line: new use cases or modified
On Thu, Jul 2, 2020 at 9:33 PM Daniel. wrote:
> Em ter., 30 de jun. de 2020 às 15:49, Alex Hall
> escreveu:
>
>> I think I'm missing something. Daniel wants a `list.get` method with
>> similar semantics to `dict.get`. So instead of writing:
>>
>> ```
>> try:
>> x = lst[i]
>> except
Em ter., 30 de jun. de 2020 às 15:49, Alex Hall
escreveu:
> I think I'm missing something. Daniel wants a `list.get` method with
> similar semantics to `dict.get`. So instead of writing:
>
> ```
> try:
> x = lst[i]
> except IndexError:
> x = default
> ```
>
> one could write `x =
Em qua, 1 de jul de 2020 00:56, David Lowry-Duda
escreveu:
> Very similar things could be said about dict.get too, no? It's easy to
> write your own function that does the same thing or to catch an
> exception.
>
> On the other hand, it seems far more likely to miss keys in a dictionary
> than
On Wed, Jul 1, 2020 at 6:23 AM Christopher Barker
wrote:
> On Tue, Jun 30, 2020 at 8:55 PM David Lowry-Duda
> wrote:
>
>> On the other hand, it seems far more likely to miss keys in a dictionary
>> than it is to repeatedly mistake indices in a list.
>>
>
> exactly -- dict keys are arbitrary,
On Tue, Jun 30, 2020 at 8:55 PM David Lowry-Duda
wrote:
> On the other hand, it seems far more likely to miss keys in a dictionary
> than it is to repeatedly mistake indices in a list.
>
exactly -- dict keys are arbitrary, and it's pretty common to store
"sparse" data by simply leaving out the
Very similar things could be said about dict.get too, no? It's easy to
write your own function that does the same thing or to catch an
exception.
On the other hand, it seems far more likely to miss keys in a dictionary
than it is to repeatedly mistake indices in a list.
> Which would be the
toolz.get_in is designed for exactly this.
https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.get_in
The whole library is great!
Alex
On Wed, 1 Jul 2020 at 8:03 am, MRAB wrote:
> On 2020-06-30 23:26, Daniel. wrote:
> > I just want to make clear that safe navegator is enough to
On 2020-06-30 23:26, Daniel. wrote:
I just want to make clear that safe navegator is enough to deal with this.
Now that this is clear, the use case is almost always the same. I
received some json as response and want to extract a nested value.
The way I'm doing this today is overloading an
I just want to make clear that safe navegator is enough to deal with this.
Now that this is clear, the use case is almost always the same. I received
some json as response and want to extract a nested value.
The way I'm doing this today is overloading an infix operator (I'm using
>>) to emulate
Hello!
Which would be the use cases for this feature?
I can't think of one.
I think that "nice to have" leads to the ways of Perl.
Regards,
On Sat, Jun 27, 2020 at 9:34 AM Daniel. wrote:
> When I need to traverse nested dicts, is a common pattern to do
>
> somedict.get('foo', {}).get('bar',
I think I'm missing something. Daniel wants a `list.get` method with
similar semantics to `dict.get`. So instead of writing:
```
try:
x = lst[i]
except IndexError:
x = default
```
one could write `x = lst.get(i, default)`. How would you rewrite that with
PEP 505?
I've also wanted this a
Oh, sorry, I will take a look.
Thanks!
Em sáb., 27 de jun. de 2020 às 12:06, Guido van Rossum
escreveu:
> Please read PEP 505 before rehashing this old idea.
>
> On Sat, Jun 27, 2020 at 06:35 Daniel. wrote:
>
>> When I need to traverse nested dicts, is a common pattern to do
>>
>>
Please read PEP 505 before rehashing this old idea.
On Sat, Jun 27, 2020 at 06:35 Daniel. wrote:
> When I need to traverse nested dicts, is a common pattern to do
>
> somedict.get('foo', {}).get('bar', {})
>
> But there is no such equivalent for arrays, wouldn't be nice if we can
> follow
>
>
89 matches
Mail list logo
