Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #105866 > unrolled thread

Re: Suggestion: make sequence and map interfaces more similar

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Suggestion: make sequence and map interfaces more similar "Marco S." <mail.python.org@marco.sulla.e4ward.com> - 2016-03-27 20:01 +0200
    Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:05 +1100
      Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-29 16:08 +0200
      Re: Suggestion: make sequence and map interfaces more similar Chris Angelico <rosuav@gmail.com> - 2016-03-30 01:31 +1100
      Re: Suggestion: make sequence and map interfaces more similar Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-03-30 00:29 +0200
      Re: Suggestion: make sequence and map interfaces more similar Terry Reedy <tjreedy@udel.edu> - 2016-03-29 20:55 -0400
      Re: Suggestion: make sequence and map interfaces more similar Chris Angelico <rosuav@gmail.com> - 2016-03-30 11:56 +1100
      Re: Suggestion: make sequence and map interfaces more similar Random832 <random832@fastmail.com> - 2016-03-29 23:38 -0400
        Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-30 16:43 +1100
          Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-30 16:57 +1100
          Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 10:12 +0300
            Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-30 21:17 +1100
              Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 13:28 +0300
                Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-30 12:34 +0200
                  Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 13:57 +0300
                Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-30 23:22 +1100
                  Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-30 15:12 +0200
                    Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-31 02:56 +1100
                      Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-30 21:07 +0200
                        Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-31 13:40 +1100
                          Re: Suggestion: make sequence and map interfaces more similar Paul Rubin <no.email@nospam.invalid> - 2016-03-30 19:45 -0700
                            Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-31 17:45 +1100
                          Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-31 09:52 +0200
                            Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-31 21:36 +1100
                              Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-31 12:51 +0200
                              Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-31 13:22 +0200
                              Re: Suggestion: make sequence and map interfaces more similar Chris Angelico <rosuav@gmail.com> - 2016-03-31 22:57 +1100
                                Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-31 15:36 +0300
                                  Re: Suggestion: make sequence and map interfaces more similar Chris Angelico <rosuav@gmail.com> - 2016-03-31 23:48 +1100
                                    Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-31 17:02 +0300
                                      Re: Suggestion: make sequence and map interfaces more similar Michael Selik <michael.selik@gmail.com> - 2016-04-01 04:19 -0400
                                  Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-31 15:55 +0300
                                    Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-31 17:19 +0300
                              Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-31 15:08 +0200
                                Re: Suggestion: make sequence and map interfaces more similar Rustom Mody <rustompmody@gmail.com> - 2016-03-31 06:42 -0700
                              Re: Suggestion: make sequence and map interfaces more similar Chris Angelico <rosuav@gmail.com> - 2016-04-01 00:11 +1100
                              Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-31 14:17 +0100
                              Re: Suggestion: make sequence and map interfaces more similar Random832 <random832@fastmail.com> - 2016-03-31 09:27 -0400
                                Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-31 17:13 +0300
                                  Re: Suggestion: make sequence and map interfaces more similar Terry Reedy <tjreedy@udel.edu> - 2016-03-31 13:41 -0400
                              Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-31 15:12 +0100
                              Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-04-01 09:59 +0200
                              Re: Suggestion: make sequence and map interfaces more similar Tim Golden <mail@timgolden.me.uk> - 2016-04-01 09:27 +0100
                                Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-04-01 21:38 +1100
                                  Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-04-01 13:50 +0300
                                Re: Suggestion: make sequence and map interfaces more similar Rustom Mody <rustompmody@gmail.com> - 2016-04-01 07:41 -0700
                              Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-04-01 10:04 +0100
                      Re: Suggestion: make sequence and map interfaces more similar Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-03-30 21:35 +0200
                      Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-30 21:31 +0100
              Re: Suggestion: make sequence and map interfaces more similar Manolo Martínez <manolo@austrohungaro.com> - 2016-03-30 12:26 +0200
                Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 13:40 +0300
                  Re: Suggestion: make sequence and map interfaces more similar Manolo Martínez <manolo@austrohungaro.com> - 2016-03-30 12:50 +0200
                    Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 14:21 +0300
                      Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-30 14:44 +0300
                        Re: Suggestion: make sequence and map interfaces more similar Manolo Martínez <manolo@austrohungaro.com> - 2016-03-30 14:29 +0200
                          Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-30 15:55 +0300
                            Re: Suggestion: make sequence and map interfaces more similar Manolo Martínez <manolo@austrohungaro.com> - 2016-03-30 15:13 +0200
                      Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-30 23:27 +1100
                        Re: Suggestion: make sequence and map interfaces more similar Marko Rauhamaa <marko@pacujo.net> - 2016-03-30 15:48 +0300
                          Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 17:38 +0300
                        Re: Suggestion: make sequence and map interfaces more similar Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-30 17:25 +0300
          Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-30 10:55 +0200
          Re: Suggestion: make sequence and map interfaces more similar Random832 <random832@fastmail.com> - 2016-03-30 08:50 -0400
            Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-31 03:02 +1100
              Re: Suggestion: make sequence and map interfaces more similar Random832 <random832@fastmail.com> - 2016-03-30 12:52 -0400
                Re: Suggestion: make sequence and map interfaces more similar Steven D'Aprano <steve@pearwood.info> - 2016-03-31 13:44 +1100
                  Re: Suggestion: make sequence and map interfaces more similar Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-31 10:04 +0200
                  Re: Suggestion: make sequence and map interfaces more similar Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-03-31 13:58 +0200
                  Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-31 13:30 +0100
                  Re: Suggestion: make sequence and map interfaces more similar Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-03-31 14:49 +0200
                  Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-31 14:14 +0100
              Re: Suggestion: make sequence and map interfaces more similar Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-03-30 22:00 +0200
              Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-30 21:36 +0100
      Re: Suggestion: make sequence and map interfaces more similar Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-30 08:03 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#106122

Steven D'Aprano <steve@pearwood.info> writes:
> I want to see an actual application where adding a new key to a
> mapping is expected to change the other keys.

directory["mary.roommate"] = "bob"
directory["mary.address"] = None   # unknown address
...
directory["bob.address"] = "132 Elm Street"

Since Bob and Mary are roommates, they have the same address, so the
application might want to update both addresses once it learns one of
them.

[toc] | [prev] | [next] | [standalone]

#106135

On Thursday 31 March 2016 13:45, Paul Rubin wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
>> I want to see an actual application where adding a new key to a
.................^^^^^^^^^^^^^^^^^^^^^

>> mapping is expected to change the other keys.

> directory["mary.roommate"] = "bob"
> directory["mary.address"] = None   # unknown address
> ...
> directory["bob.address"] = "132 Elm Street"
> 
> Since Bob and Mary are roommates, they have the same address, so the
> application might want to update both addresses once it learns one of
> them.

I think I've used that application! It was a nightmare... I had to move 
house seven times before I stopped getting my ex-roomate Stinky Joe's 
electricity bill sent to me.

Nah, only kidding. I've never seen such an application, and I don't believe 
it exists. By your use of the word "might", I'm guessing that you've made it 
up. But even if you didn't, it's still a lousy design. Just because Mary and 
Bob are roommates *now* doesn't mean that they are joined at the hips like 
Siamese twins and are roommates forever. If Mary relocates, the application 
shouldn't automatically relocate Bob as well.

And even if the application does, for some strange reason, this logic should 
be built into the *application itself*, not into dict. By all means subclass 
dict and make your own fancy mapping type that has all sorts of application-
specific smarts (or dumbs, as the case may be). Just don't expect it in the 
standard dict.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#106137

Op 31-03-16 om 04:40 schreef Steven D'Aprano:
> On Thu, 31 Mar 2016 06:07 am, Antoon Pardon wrote:
>
>>> Because fundamentally, it doesn't matter whether dicts are surjections or
>>> not. They're still many-to-one mappings, and those mappings between keys
>>> and values should not change due to the insertion or deletion of
>>> unrelated keys.
>> Repeating your opion without further arguments doesn't lend any support
>> to that opinion. If within the problem space you are working on, such a
>> change would make sense as a step to generate the next mapping from the
>> previous one, i don't see what the problem is if one could make use of
>> this.
>
> Enough of the hypothetical arguments about what one could do or might do.
> Let's see a concrete example of actual real world code used in production,
> not a mickey-mouse toy program, where it is desirable that adding or
> deleting one key will modify the rest of the keys in the mapping.

I am not going to humour your petitio principii. If you want to argue against
such a adjustment on the ground of some characteristics mappings should have,
you have to make your case yourself and not try to shift the burden onto
the person who has his doubt about your argument.

If you continously stress the adaption will loose the stability of mappings
and so suggest this is somehow a problem it is your burden to argue that
problem.

> Arguing for the sake of arguing about what somebody might want is not
> productive. Let's see some actual concrete use cases where you have a
> database or mapping between keys and values, say something like this:

Arguing by just calling attention to a specific characteristic but not
giving any reason why it would be bad if people were allowed to use a
mapping in a way that violated this characteristic, is not productive
either.

If you try to argue a principle problem with the proposal, you have
to support that and not try to shift the attention to there being no
use case for the moment.

-- 
Antoon Pardon.

[toc] | [prev] | [next] | [standalone]

#106142

On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote:

> it is your burden to argue that problem.

No it isn't. I don't have to do a thing. All I need to do is sit back and
wait as this discussion peters off into nothing. The burden isn't on me to
justify the status quo. The burden is on those who want to make this change
to justify the change, because if you don't, the status quo stays exactly
the same.

And if you're brave enough to take to this Python-Ideas, let alone
Python-Dev, the first question they'll ask is "What's your use-case?". And
since you don't have one, this discussion will go nowhere.

Oh, there might be a few hundred posts on the topic, from people
bike-shedding it, but unless you convince the core developers, all the
chattering in the world won't get you one nanometre closer to changing the
behaviour of lists and dicts.

So, Antoon, no, I don't have to justify a single thing. If you want this
change, you have to justify why it should be done.

Good luck with that.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#106143

Op 31-03-16 om 12:36 schreef Steven D'Aprano:
> On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote:
>
>> it is your burden to argue that problem.
> No it isn't. I don't have to do a thing.

If that is how you think about this, why do you contribute? I completly
understand if you are of the opinion that other priorities are more
important 

>  All I need to do is sit back and
> wait as this discussion peters off into nothing. The burden isn't on me to
> justify the status quo. The burden is on those who want to make this change
> to justify the change, because if you don't, the status quo stays exactly
> the same.
>
> And if you're brave enough to take to this Python-Ideas, let alone
> Python-Dev, the first question they'll ask is "What's your use-case?". And
> since you don't have one, this discussion will go nowhere.
>
> Oh, there might be a few hundred posts on the topic, from people
> bike-shedding it, but unless you convince the core developers, all the
> chattering in the world won't get you one nanometre closer to changing the
> behaviour of lists and dicts.
>
> So, Antoon, no, I don't have to justify a single thing. If you want this
> change, you have to justify why it should be done.
>
> Good luck with that.
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#106145

Op 31-03-16 om 12:36 schreef Steven D'Aprano:
> On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote:
>
>> it is your burden to argue that problem.
> No it isn't. I don't have to do a thing. All I need to do is sit back and
> wait as this discussion peters off into nothing. The burden isn't on me to
> justify the status quo. The burden is on those who want to make this change
> to justify the change, because if you don't, the status quo stays exactly
> the same.

Sure that is all very well if you stay out of the discussion, or limit
your contribution to mentioning that in your opinion that this is a
very low priority. I have no problem with that. But if you begin to
argue that the proposal has flaws and you argue against it then it
is your intellectual responsibility to support your arguments.

There is a difference between, (1) this proposal is flawed and (2)I
don't think this is important enough. Starting with the first and then
when pressed to support it, retreating to the second is not fair.

> And if you're brave enough to take to this Python-Ideas, let alone
> Python-Dev, the first question they'll ask is "What's your use-case?". And
> since you don't have one, this discussion will go nowhere.

So? That doesn't relieve you of your responsibility when you somehow
argue that the proposal is flawed, beyond there being no use case.

> Oh, there might be a few hundred posts on the topic, from people
> bike-shedding it, but unless you convince the core developers, all the
> chattering in the world won't get you one nanometre closer to changing the
> behaviour of lists and dicts.

I have no interest in convincing the core developers. That doesn't mean
I can't respond here to arguments against a proposal that are IMO bogus.
A bogus argument against a proposal doesn't become a good argument against
because there is no use case.

> So, Antoon, no, I don't have to justify a single thing. If you want this
> change, you have to justify why it should be done.

Indeed you don't have to argue against any proposal. You can just sit back
and ask for use cases and ask do be convinced this proposal is important
enough for the core developers to invest time in. But once you do argue against
a proposal, as you did here, you have loaded yourself with the burden to
support your argument. Because then your position is that even with an
import use case, this is still a bad idea. And if you can't support that
position it isn't fair IMO to then retreat to the "no use case" position
as if that somehow is a defence of your argued position.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#106146

On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 31-03-16 om 12:36 schreef Steven D'Aprano:
>> On Thu, 31 Mar 2016 06:52 pm, Antoon Pardon wrote:
>>
>>> it is your burden to argue that problem.
>> No it isn't. I don't have to do a thing. All I need to do is sit back and
>> wait as this discussion peters off into nothing. The burden isn't on me to
>> justify the status quo. The burden is on those who want to make this change
>> to justify the change, because if you don't, the status quo stays exactly
>> the same.
>
> Sure that is all very well if you stay out of the discussion, or limit
> your contribution to mentioning that in your opinion that this is a
> very low priority. I have no problem with that. But if you begin to
> argue that the proposal has flaws and you argue against it then it
> is your intellectual responsibility to support your arguments.
>
> There is a difference between, (1) this proposal is flawed and (2)I
> don't think this is important enough. Starting with the first and then
> when pressed to support it, retreating to the second is not fair.
>

Okay. I'll put a slightly different position: Prove that your proposal
is worth discussing by actually giving us an example that we can
discuss. So far, this thread has had nothing but toy examples (and
bogoexamples that prove nothing beyond that the author knows how to
mess with Python - fun, but not a strong argument on either side).
Give us some real meat to work with, instead of these drips of
tantalizing blood.

ChrisA

[toc] | [prev] | [next] | [standalone]

#106149

Chris Angelico <rosuav@gmail.com>:

> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
> Okay. I'll put a slightly different position: Prove that your proposal
> is worth discussing by actually giving us an example that we can
> discuss.

Sorry for missing most of the arguments here, but if you are talking
about treating lists as special cases of dicts, I have occasionally
instinctively wanted something like this:

    >>> fields = [ "x", "y", "z" ]
    >>> selector = (1, 1, 0)
    >>> list(map(fields.get, selector))
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    AttributeError: 'list' object has no attribute 'get'

analogously with:

    >>> field_dict = { 0: "x", 1: "y", 2: "z" }
    >>> list(map(field_dict.get, selector))
    ['y', 'y', 'x']

Or course, I could:

    >>> list(map(fields.__getitem__, selector))
    ['y', 'y', 'x']

but that would abuse a dunder method. So I will need to:

    >>> list(map(lambda i: fields[i], selector))
    ['y', 'y', 'x']

or (most likely):

    >>> new_fields = []
    >>> for i in selector:
    ...   new_fields.append(fields[i])
    ...
    >>> new_fields
    ['y', 'y', 'x']


This tiny problem of mine could be remedied by adding a get method to
lists.


Marko

[toc] | [prev] | [next] | [standalone]

#106150

On Thu, Mar 31, 2016 at 11:36 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
>> <antoon.pardon@rece.vub.ac.be> wrote:
>> Okay. I'll put a slightly different position: Prove that your proposal
>> is worth discussing by actually giving us an example that we can
>> discuss.
>
> Sorry for missing most of the arguments here, but if you are talking
> about treating lists as special cases of dicts, I have occasionally
> instinctively wanted something like this:
>
>     >>> fields = [ "x", "y", "z" ]
>     >>> selector = (1, 1, 0)
>     >>> list(map(fields.get, selector))
>     Traceback (most recent call last):
>     File "<stdin>", line 1, in <module>
>     AttributeError: 'list' object has no attribute 'get'
>
> Or course, I could:
>
>     >>> list(map(fields.__getitem__, selector))
>     ['y', 'y', 'x']
>
> but that would abuse a dunder method. So I will need to:
>
>     >>> list(map(lambda i: fields[i], selector))
>     ['y', 'y', 'x']
>
> or (most likely):
>
>     >>> new_fields = []
>     >>> for i in selector:
>     ...   new_fields.append(fields[i])
>     ...
>     >>> new_fields
>     ['y', 'y', 'x']
>
>
> This tiny problem of mine could be remedied by adding a get method to
> lists.

Or, even more likely and even more Pythonic:

>>> [fields[i] for i in selector]
['y', 'y', 'x']

As soon as you get past the easy and obvious case of an existing
function, filter and map quickly fall behind comprehensions in utility
and readability.

ChrisA

[toc] | [prev] | [next] | [standalone]

#106160

Chris Angelico <rosuav@gmail.com>:

> Or, even more likely and even more Pythonic:
>
>>>> [fields[i] for i in selector]
> ['y', 'y', 'x']
>
> As soon as you get past the easy and obvious case of an existing
> function, filter and map quickly fall behind comprehensions in utility
> and readability.

The general need is contexts where you need fields[?] act as a function.
Of course,

   lambda i: fields[i]

does it. However, weirdly, dicts have get but lists don't.

Ok, dict.get() provides for a default value, but couldn't that come in
handy for lists as well?

Again, lambda would do it for both dicts and lists:

   lambda i: fields[i] if i >= 0 and i < len(fields) else default

   lambda key: fields[key] if key in fields else default


Marko

[toc] | [prev] | [next] | [standalone]

#106209

> On Mar 31, 2016, at 10:02 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> 
> However, weirdly, dicts have get but lists don't.

Read PEP 463 for discussion on this topic.
https://www.python.org/dev/peps/pep-0463/

[toc] | [prev] | [next] | [standalone]

#106152

Marko Rauhamaa writes:

> Chris Angelico wrote:
>
>> Okay. I'll put a slightly different position: Prove that your
>> proposal is worth discussing by actually giving us an example that we
>> can discuss.
>
> Sorry for missing most of the arguments here, but if you are talking
> about treating lists as special cases of dicts, I have occasionally
> instinctively wanted something like this:
>
>     >>> fields = [ "x", "y", "z" ]
>     >>> selector = (1, 1, 0)
>     >>> list(map(fields.get, selector))
>     Traceback (most recent call last):
>     File "<stdin>", line 1, in <module>
>     AttributeError: 'list' object has no attribute 'get'

operator.itemgetter(*selector)(fields) # ==> ('y', 'y', 'x')

> analogously with:
>
>     >>> field_dict = { 0: "x", 1: "y", 2: "z" }
>     >>> list(map(field_dict.get, selector))
>     ['y', 'y', 'x']

operator.itemgetter(*selector)(field_dict) # ==> ('y', 'y', 'x')

It's not quite the same but it's close and it works the same for
strings, lists, dicts, ...

[toc] | [prev] | [next] | [standalone]

#106163

Jussi Piitulainen <jussi.piitulainen@helsinki.fi>:

> operator.itemgetter(*selector)(fields) # ==> ('y', 'y', 'x')
>
> [...]
>
> operator.itemgetter(*selector)(field_dict) # ==> ('y', 'y', 'x')
>
> It's not quite the same but it's close and it works the same for
> strings, lists, dicts, ...

Not quite the same, but nicely found anyway.


Marko

[toc] | [prev] | [next] | [standalone]

#106153

Op 31-03-16 om 13:57 schreef Chris Angelico:
> Okay. I'll put a slightly different position: Prove that your proposal
> is worth discussing by actually giving us an example that we can
> discuss. So far, this thread has had nothing but toy examples (and
> bogoexamples that prove nothing beyond that the author knows how to
> mess with Python - fun, but not a strong argument on either side).
> Give us some real meat to work with, instead of these drips of
> tantalizing blood.

What a strange request. Whether or not something is worth discussing
is a personal judgement. So there can be no proof of such a thing.
I would say: judge for yourself and act accordingly.

-- 
Antoon

[toc] | [prev] | [next] | [standalone]

#106158

On Thursday, March 31, 2016 at 6:38:56 PM UTC+5:30, Antoon Pardon wrote:
> Op 31-03-16 om 13:57 schreef Chris Angelico:
> > Okay. I'll put a slightly different position: Prove that your proposal
> > is worth discussing by actually giving us an example that we can
> > discuss. So far, this thread has had nothing but toy examples (and
> > bogoexamples that prove nothing beyond that the author knows how to
> > mess with Python - fun, but not a strong argument on either side).
> > Give us some real meat to work with, instead of these drips of
> > tantalizing blood.
> 
> What a strange request. Whether or not something is worth discussing
> is a personal judgement. So there can be no proof of such a thing.
> I would say: judge for yourself and act accordingly.

Not been following this thread much
And not much interest in the suggestion/request
Just thought I'd give a take on what may be the motivation for this

There is the allure of One-Fundamental-Data-structure
Lisp calls that 'list'
[40 years after with more fanfare and less clarity replicated as XML]

Math calls that 'function'
Even more fundamental in CS than in math
That maps are same as functions is standard math.
In python one interconverts data→code by going from dict d to d.get
code→data by memoization/caching
How about a Grand Unified Theory?

[Just to be clear -- not my interest or wish]

[toc] | [prev] | [next] | [standalone]

#106154

On Fri, Apr 1, 2016 at 12:08 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 31-03-16 om 13:57 schreef Chris Angelico:
>> Okay. I'll put a slightly different position: Prove that your proposal
>> is worth discussing by actually giving us an example that we can
>> discuss. So far, this thread has had nothing but toy examples (and
>> bogoexamples that prove nothing beyond that the author knows how to
>> mess with Python - fun, but not a strong argument on either side).
>> Give us some real meat to work with, instead of these drips of
>> tantalizing blood.
>
> What a strange request. Whether or not something is worth discussing
> is a personal judgement. So there can be no proof of such a thing.
> I would say: judge for yourself and act accordingly.

Plonk.

ChrisA

[toc] | [prev] | [next] | [standalone]

#106156

On 31/03/2016 14:08, Antoon Pardon wrote:
> Op 31-03-16 om 13:57 schreef Chris Angelico:
>> Okay. I'll put a slightly different position: Prove that your proposal
>> is worth discussing by actually giving us an example that we can
>> discuss. So far, this thread has had nothing but toy examples (and
>> bogoexamples that prove nothing beyond that the author knows how to
>> mess with Python - fun, but not a strong argument on either side).
>> Give us some real meat to work with, instead of these drips of
>> tantalizing blood.
>
> What a strange request. Whether or not something is worth discussing
> is a personal judgement. So there can be no proof of such a thing.
> I would say: judge for yourself and act accordingly.
>

Drivel.  This is comp.lang.python, where "Practicality beats purity" 
every time, not comp.theoretical.claptrap.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#106157

On Thu, Mar 31, 2016, at 09:17, Mark Lawrence via Python-list wrote:
> On 31/03/2016 14:08, Antoon Pardon wrote:
> > Op 31-03-16 om 13:57 schreef Chris Angelico:
> >> Okay. I'll put a slightly different position: Prove that your proposal
> >> is worth discussing by actually giving us an example that we can
> >> discuss. So far, this thread has had nothing but toy examples (and
> >> bogoexamples that prove nothing beyond that the author knows how to
> >> mess with Python - fun, but not a strong argument on either side).
> >> Give us some real meat to work with, instead of these drips of
> >> tantalizing blood.
> >
> > What a strange request. Whether or not something is worth discussing
> > is a personal judgement. So there can be no proof of such a thing.
> > I would say: judge for yourself and act accordingly.
> 
> Drivel.  This is comp.lang.python, where "Practicality beats purity" 
> every time, not comp.theoretical.claptrap.

So can we discuss how a unified method to get a set of all valid
subscripts (and/or subscript-value pairs) on an object would be a useful
thing to have without getting bogged down in theoretical claptrap about
the meaning of the mapping contract?

[toc] | [prev] | [next] | [standalone]

#106161

Random832 <random832@fastmail.com>:

> So can we discuss how a unified method to get a set of all valid
> subscripts (and/or subscript-value pairs) on an object would be a
> useful thing to have without getting bogged down in theoretical
> claptrap about the meaning of the mapping contract?

One could compose a table of correspondences:

      -------------------------------------------
      list (L)                    dict (D)       
      -------------------------------------------
      L[key] = value              D[key] = value
      del L[key] (*)              del L[key]         
      key >= 0 and key < len(L)   key in D
      range(len(L))               iter(D)
      L.clear                     D.clear
      L.copy                      D.copy
      lambda key: L[key]          D.get
      lambda: enumerate(L)        D.items
      lambda: range(len(L))       D.keys
             ...                    ...
      -------------------------------------------
      (*) reassigns all keys


Marko

[toc] | [prev] | [next] | [standalone]

#106176

On 3/31/2016 10:13 AM, Marko Rauhamaa wrote:

> One could compose a table of correspondences:

with some corrections

>        -------------------------------------------
>        list (L)                    dict (D)
>        -------------------------------------------
>        L[key] = value              D[key] = value
>        del L[key] (*)              del L[key]
>        (*) reassigns all keys
>        key >= 0 and key < len(L)   key in D

'-len(L) <= key < len(L)' or 'key in range(-len(L), len(L)'
Lists, tuples, and ranges have 2 keys for each value,
though that is not guaranteed for sequences in general.

key in D == key in D.keys()

>        range(len(L))               iter(D)

          iter(range(Len(L))          == iter(D.keys())

>        L.clear                     D.clear
>        L.copy                      D.copy
>        lambda key: L[key]          D.get

The purpose of D.get() is to supply a default instead of raising 
KeyError when key not in D. The lambda function above does not do that. 
  Turning subscripting into a function is a side-effect of D.get.  A 
generic get function:

def get(subscriptable, key, default=None):
     try:
         return subscriptable[key]
     except (IndexError, KeyError):
         return default

>        lambda: enumerate(L)        D.items

As I pointed out a couple days ago, an enumerate iterator is quite 
different from a set-like dynamic view.  An actual correspondence:

          enumerate(L)               iter(D.items())

Writing a set-like dynamic view of lists corresponding to D.values() or 
D.items() would be an interesting project.

>        lambda: range(len(L))       D.keys

          iter(range(len(L))          iter(D.keys())
Already given above.  Iterating indexes is now much rarer than iterating 
dict keys.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web