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 4 of 4 — ← Prev page 1 2 3 [4]

#106075

Steven D'Aprano writes:

> On Wed, 30 Mar 2016 10:21 pm, Jussi Piitulainen wrote:
>
>> Ok, safer to say that some many-to-one mappings are not surjective.
>
> Can you give an example of a Python dict which is not surjective?

Can you give an example of a mapping which is not surjective? Can you
represent it as a Python dict?

Surjectivity requires a specified codomain. Python dicts as such do not
have one.

The Wikipedia article that you cite (the one that doesn't say what you
think it says) is about functions f that have a specified domain, which
is some set A, and a specified codomain, which is some set B. They
indicate this by writing f : A -> B. (I'm not sure if I need to point
out that the A and B in that notation in the text need not have anything
to do with the A and B in the diagrams next to the text on top of the
page. Instead they correspond to the X and Y in the diagrams.)

Do you think {1: 'D', 2: 'B', 3: 'A'} is surjective?

Do you think {1: 'd', 2: 'd', 3: 'c'} is surjective?

Those are the Wikipedia examples of non-surjective mappings on top of
the page.

Strictly speaking, these dicts represent the *graphs* of the functions,
and set("ABD") and set("cd") are the *images* of the two mappings. The
specified codomains are not recoverable from the dicts. (Do I need to
point out that the A, B, C, D and a, b, c, d in the diagrams are
abstract placeholders rather than characters or one-character strings
but using Python strings in their place does not change the abstract
structure of the data, and it's intended in these diagrams that they are
four different things when they are inside the same oval even though
that doesn't seem to be made explicit in the page?)

Yes, the restriction of any mapping to its image is surjective. No, this
does not make it even minimally informative to say of any particular
mapping that its restriction to its image is surjective - its image is
its image? Of course it is.

But it may be informative to say of a dict whether it has at least one
key for every value *in some intended codomain* - whether its image is
its codomain. That is surjectivity.

(I'm running out of pedantry, but just in case: I'm quite aware that I
didn't *explicitly* rule out the possibility of values in the dict but
not in the intended codomain. Should I have? It's part of the notion of
an intended codomain that values outside of it are not allowed at all.)

I don't think this has anything to do with the topic of the thread.

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

#106037

Op 30-03-16 om 07:43 schreef Steven D'Aprano:
> Yes, we're all very impressed that you spotted the trivial and obvious 
> loophole that changing a key:value will change the key:value that you just 
> changed *wink* but that doesn't really move the discussion anywhere.
>
> This is not an argument about dicts being mutable, because clearly they 
> aren't. This is an argument about key:value pairs being stable. "Stable" 
> doesn't mean "immutable". If you change the value associated with a key 
> directly, then it will change. That's the whole point. But if you change 
> *one* key, the relationship between *other* keys and their values shouldn't 
> change.
>
> Given a surjection (many-to-one mapping) between keys and values in a 
> mapping, we expect that changing the mapping of one key will not affect 
> other keys. To be pedantic, by "change" I mean deleting the key (and, if 
> necessary, value) or reassigning a new value to the key. To be even more 
> pedantic, mutations to the value *do not count*.

I don't expect that generally. Sure there are specific mapping implementations
for which this is true, but I see no reason to limit the word mapping only to
those kind of data-types.

What I want from a mapping is that it gives me the correct correspondence between
a key and a value for the application I am using it for. If that means a "stable"
mapping I'll limit the operations on that mapping as to keep it that way. Which
in a number of case can be perfectly done with python-lists.

So generally there is no reason to limit the word "mapping" to stable mappings.

-- 
Antoon Pardon

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

#106060

On Wed, Mar 30, 2016, at 01:43, Steven D'Aprano wrote:
> This is not an argument about dicts being mutable, because clearly they 
> aren't. This is an argument about key:value pairs being stable. "Stable" 
> doesn't mean "immutable". If you change the value associated with a key 
> directly, then it will change. That's the whole point. But if you change 
> *one* key, the relationship between *other* keys and their values
> shouldn't 
> change.

This doesn't mean that an object violates the contract by having a
method that changes the relationships between multiple keys and values.
I had considered including an example of replacing the _whole
dictionary_ with a new object in the ellipsis.

Absolutely nothing is stable under a *completely unrestricted* set of
operations.

> Specifically, insertions and deletions to the mapping never affect the 
> existing keys.

You can't say that, because there is no insert and delete method in the
mapping interface.

> If somebody wants to insist that this is a kind of mapping, I can't 
> disagree, but it isn't useful as a mapping type.

Javascript seems to manage it just fine.

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

#106091

On Wed, 30 Mar 2016 11:50 pm, Random832 wrote:

> Absolutely nothing is stable under a *completely unrestricted* set of
> operations.

Yes, you're absolutely correct. If I create a Python dict, {1: 'a'}, and
then smash the computer to smithereens with a 50lb sledge hammer, neither
the key nor the value will still be accessible. Well done. I never would
have thought of that violation of the dict invariants without you.


>> Specifically, insertions and deletions to the mapping never affect the
>> existing keys.
> 
> You can't say that, because there is no insert and delete method in the
> mapping interface.

There are in the dict API though.

# insertions
d[key] = value

# deletions
del d[key]



>> If somebody wants to insist that this is a kind of mapping, I can't
>> disagree, but it isn't useful as a mapping type.
> 
> Javascript seems to manage it just fine.

I wouldn't exactly hold Javascript up as the exemplar of intelligent design
decisions.


-- 
Steven

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

#106095

This discussion is getting a bit distracted from the original request.
Let's look at it from a higher level.

What is being requested, regardless of if you call it a "map interface"
or whatever, is a single way, for sequences and maps... broadly,
anything with a __getitem__, to iterate over all values which one might
pass to __getitem__, so that one might (among other things) call
__setitem__ to mutate the collection.

Like, these are common patterns:

for i, x in enumerate(l):
   # do some stuff, sometimes assign l[i]

for k, v in d.items():
   # do some stuff, sometimes assign d[k]

A way to apply that pattern generically to an object which may be either
a sequence or a mapping might be nice. Or some other way of doing this
operation - maybe a writable iterator like C++ or Java.

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

#106121

On Thu, 31 Mar 2016 03:52 am, Random832 wrote:

> Like, these are common patterns:
> 
> for i, x in enumerate(l):
>    # do some stuff, sometimes assign l[i]
> 
> for k, v in d.items():
>    # do some stuff, sometimes assign d[k]


for a, b in zip(spam, eggs):
    # do some stuff, sometimes assign x[a] or b[a] or who knows what?


Does this mean that "lists, dicts and zip" should all support the same
interface?

Not every coincidental and trivial piece of similar code is actually
related.


> A way to apply that pattern generically to an object which may be either
> a sequence or a mapping might be nice.

Nice, and easy.

# Duck-typing version.
def iterpairs(obj):
    if hasattr(obj, 'items'):
        it = obj.items
    else:
        it = enum(obj)
    yield from it


# Type-checking version.
def iterpairs(obj):
    if isinstance(obj, collections.abc.Mapping):
        it = obj.items
    elif isinstance(obj, collections.abc.Sequence):
        it = enum(obj)
    else:
        raise TypeError('not a sequence or a mapping')
    yield from it


Pick which one you prefer, stick it in your own personal toolbox of useful
utilities functions, and off you go.




-- 
Steven

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

#106139

Op 31-03-16 om 04:44 schreef Steven D'Aprano:
> On Thu, 31 Mar 2016 03:52 am, Random832 wrote:
>
>> Like, these are common patterns:
>>
>> for i, x in enumerate(l):
>>    # do some stuff, sometimes assign l[i]
>>
>> for k, v in d.items():
>>    # do some stuff, sometimes assign d[k]
>
> for a, b in zip(spam, eggs):
>     # do some stuff, sometimes assign x[a] or b[a] or who knows what?
>
>
> Does this mean that "lists, dicts and zip" should all support the same
> interface?
>
> Not every coincidental and trivial piece of similar code is actually
> related.

But your addition shows that the similarities between lists and dicts
are greater than with zip. In the above two examples the assignment
was specific to elements of the list or dict over which was iterated.

Your x[a] and b[a] have no such relationship with the rest of your
example. This is further illustrated by the fact that your solution
doesn't provide a zip branch.

>> A way to apply that pattern generically to an object which may be either
>> a sequence or a mapping might be nice.
> Nice, and easy.
>
> # Duck-typing version.
> def iterpairs(obj):
>     if hasattr(obj, 'items'):
>         it = obj.items
>     else:
>         it = enum(obj)
>     yield from it
>
>
> # Type-checking version.
> def iterpairs(obj):
>     if isinstance(obj, collections.abc.Mapping):
>         it = obj.items
>     elif isinstance(obj, collections.abc.Sequence):
>         it = enum(obj)
>     else:
>         raise TypeError('not a sequence or a mapping')
>     yield from it
>
>
> Pick which one you prefer, stick it in your own personal toolbox of useful
> utilities functions, and off you go.
>
>
>
>

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

#106147

On 31 March 2016 at 04:40, Steven D'Aprano <steve@pearwood.info> wrote:
> 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.


1. the example was for confuting your assertion that an implementation
of sequences as extended classes of maps violate the map contract.
2. I already linked a real-world example previously. Google it and you
can find tons of examples like that.


On 31 March 2016 at 04:44, Steven D'Aprano <steve@pearwood.info> wrote:
> for a, b in zip(spam, eggs):
>     # do some stuff, sometimes assign x[a] or b[a] or who knows what?
>
>
> Does this mean that "lists, dicts and zip" should all support the same
> interface?

I do not understand what you mean with this example. A zip object is
not a sequence nor a map. My definition of sequences as "ordered maps
with integer keys that start from zero and have no gaps" is perfectly
valid as I demonstrated to you, while zip objects have nothing in
common with sequences and maps, apart the fact they are all iterables.

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

#106148

On 31/03/2016 12:58, Marco Sulla via Python-list wrote:
> On 31 March 2016 at 04:40, Steven D'Aprano <steve@pearwood.info> wrote:
>> 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.
>
>
> 1. the example was for confuting your assertion that an implementation
> of sequences as extended classes of maps violate the map contract.
> 2. I already linked a real-world example previously. Google it and you
> can find tons of examples like that.
>
>
> On 31 March 2016 at 04:44, Steven D'Aprano <steve@pearwood.info> wrote:
>> for a, b in zip(spam, eggs):
>>      # do some stuff, sometimes assign x[a] or b[a] or who knows what?
>>
>>
>> Does this mean that "lists, dicts and zip" should all support the same
>> interface?
>
> I do not understand what you mean with this example. A zip object is
> not a sequence nor a map. My definition of sequences as "ordered maps
> with integer keys that start from zero and have no gaps" is perfectly
> valid as I demonstrated to you, while zip objects have nothing in
> common with sequences and maps, apart the fact they are all iterables.
>

The definition of sequence is given here 
https://docs.python.org/3/glossary.html#term-sequence.

<quote>
     An iterable which supports efficient element access using integer 
indices via the __getitem__() special method and defines a __len__() 
method that returns the length of the sequence. Some built-in sequence 
types are list, str, tuple, and bytes. Note that dict also supports 
__getitem__() and __len__(), but is considered a mapping rather than a 
sequence because the lookups use arbitrary immutable keys rather than 
integers.

     The collections.abc.Sequence abstract base class defines a much 
richer interface that goes beyond just __getitem__() and __len__(), 
adding count(), index(), __contains__(), and __reversed__(). Types that 
implement this expanded interface can be registered explicitly using 
register().
</quote>

As this is a Python list the above definition clearly takes priority 
over your definition, so can you please take this discussion offline, 
thanks.

-- 
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]

#106151

I want also to add that we are focusing on sequences, but my proposal
is also to make map interface more similar, introducing a vdict type
that iterates over values, and this will be for me really more
practical. PEP 234 (  http://legacy.python.org/dev/peps/pep-0234/ )
never convinced me. Van Rossum said:

> The symmetry between "if x in y" and "for x in y"
> suggests that it should iterate over keys.  This symmetry has been
> observed by many independently and has even been used to "explain"
> one using the other.  This is because for sequences, "if x in y"
> iterates over y comparing the iterated values to x.

This argument will never convinced me. It's a lot more practical (as
Van Rossum admitted further) to iterate over values by default on
maps. Furthermore I see much more symmetry between keys of maps and
indexes of sequences, so it's much more natural to make map iteration
over values by default, as for sequences. This is why I proposed a
vdict.


On 31 March 2016 at 14:30, Mark Lawrence via Python-list
<python-list@python.org> wrote:
> Note that dict also supports
> __getitem__() and __len__(), but is considered a mapping rather than a
> sequence because the lookups use arbitrary immutable keys rather than
> integers.

Thank you for confirming for what I already wrote and quoted, but I suppose you
missed some of my previous messages, my dear friend.

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

#106155

On 31/03/2016 13:49, Marco Sulla via Python-list wrote:
>
> On 31 March 2016 at 14:30, Mark Lawrence via Python-list
> <python-list@python.org> wrote:
>> Note that dict also supports
>> __getitem__() and __len__(), but is considered a mapping rather than a
>> sequence because the lookups use arbitrary immutable keys rather than
>> integers.
>
> Thank you for confirming for what I already wrote and quoted, but I suppose you
> missed some of my previous messages, my dear friend.
>

Thanks for misquoting me by deliberately snipping the bit about taking 
this completely useless discussion offline.  Please do not "dear friend" 
me as I don't take kindly to people who go out of their way to waste 
time and effort on this list.  This just isn't going to happen, so 
please drop it, or do you not realise when you're fighting a losing 
battle, and it's time to retreat?

There are of course other options, you could join in the effort to 
produce Python 2.8 or RickedPython.  I'm sure that they'd welcome some 
additional help and your patch for your absolutely awesome suggestion.

-- 
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]

#106110

Let me also add that even if it seems that my idea will not break any
official contracts, I can create a new ABC class and let maps and
sequence types inherit from it. IMHO it's absolutely not needed, but
at least the discussion will be no more distracted my secondary
considerations, since the main topic is about the usefulness and the
advantage to have a base contract for maps and sequences.

PS: I intend to write:
You've demonstrated to be a fair thinker, so do not fall into
temptation to play with
words.
My English is terrible as much as StrangeDict code.

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

#106112

On 30/03/2016 21:00, Marco Sulla via Python-list wrote:
> Let me also add that even if it seems that my idea will not break any
> official contracts, I can create a new ABC class and let maps and
> sequence types inherit from it. IMHO it's absolutely not needed, but
> at least the discussion will be no more distracted my secondary
> considerations, since the main topic is about the usefulness and the
> advantage to have a base contract for maps and sequences.

1) maps ain't sequences, sequences ain't maps, and never the twain shall 
meet.
2) if it ain't broke, don't fix it.
3) KISS

>
> PS: I intend to write:
> You've demonstrated to be a fair thinker, so do not fall into
> temptation to play with
> words.

No idea at all what you mean by this, please explain.

> My English is terrible as much as StrangeDict code.
>

StrangeDict broke "Practicality beats purity", no further comment needed.

-- 
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]

#106030

On 29/03/2016 23:29, Marco Sulla via Python-list wrote:
>
> Let me add that an items() and keys() for sequences will be also
> useful for day-by-day programming, since they will be a shortcut for
> enumerate(seq) and range(len(seq))
>

I cannot remember the last time I needed range(len(seq)) so I don't see 
how it can be "useful for day-by-day programming".  There is usually a 
more Pythonic way of doing things.  You need to get adjacent elements 
from a sequence?  Use the pairwise recipe from 
https://docs.python.org/3/library/itertools.html.

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

Mark Lawrence

[toc] | [prev] | [standalone]

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

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

csiph-web