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

#106162

On 31/03/2016 14:27, Random832 wrote:
> 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?
>

We can discuss anything here until the cows come home, but it's a 
complete waste of time if the powers that be over on python-ideas and/or 
python-dev don't agree.  This was suggested a day or two back but seems 
to have gone completely over people's heads.

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

#106208

Op 31-03-16 om 16:12 schreef Mark Lawrence via Python-list:
> On 31/03/2016 14:27, Random832 wrote:
>> 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?
>>
>
> We can discuss anything here until the cows come home, but it's a
> complete waste of time if the powers that be over on python-ideas
> and/or python-dev don't agree.  This was suggested a day or two back
> but seems to have gone completely over people's heads.

Just because you are not interested, doesn't mean it's a complete waste of time.
Discussions like this often enough produce suggestions on how one could handle
these things within python without the need for the powers that be to agree on
anything.

If you are not interested just don't contribute. Others can make up their own
mind on whether this is a waste of their time or not.

-- 
Antoon. 

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

#106210

On 01/04/2016 08:59, Antoon Pardon wrote:
> Op 31-03-16 om 16:12 schreef Mark Lawrence via Python-list:
>> On 31/03/2016 14:27, Random832 wrote:
>>> 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?
>>>
>>
>> We can discuss anything here until the cows come home, but it's a
>> complete waste of time if the powers that be over on python-ideas
>> and/or python-dev don't agree.  This was suggested a day or two back
>> but seems to have gone completely over people's heads.
> 
> Just because you are not interested, doesn't mean it's a complete waste of time.
> Discussions like this often enough produce suggestions on how one could handle
> these things within python without the need for the powers that be to agree on
> anything.
> 
> If you are not interested just don't contribute. Others can make up their own
> mind on whether this is a waste of their time or not.

FWIW I'm broadly with Antoon here: wider-ranging discussions can be
interesting and useful. (And informative, especially where people speak
knowledgeably about an area outside my own competence). There *are*
technical forums where anything outside their strict subject matter is
frowned upon or curtailed. I don't think we need to be that rigid here.

However I think there are a couple of lines which can be crossed. In one
case a a poster (perhaps abruptly) says: I think Python should do this;
why doesn't it? The other is where the discussion goes so far into
cloud-cuckoo land that it alienates all but a few devoted adherents to
the thread. Especially where it goes round in circles.

For the latter, I take the view that I know where the delete key is (or
the "ignore thread" button or whatever) and I just skip the thread when
it shows up. Perhaps missing some interesting points in the process if
it comes back down to earth but that's the way it goes.

For the former, I think it's fine if someone is asking in a genuine
spirit of enquiry, ie to learn about the history of a particular
decision or the ramifications of an alternative which might not be
obvious at first glance. (Why do we have both lists and tuples? Why does
Python index from 0? etc). People who know something about it can
explain if they wish.

If it becomes clear that the poster is in fact pushing for a change
(either intelligently thought-out or naively ill-considered) then I
would push them towards Python-ideas sooner than later, because that's
exactly the purpose of *that* mailing list. People on python-ideas want
to go to and fro over the relative merits of proposals. Specifically, I
believe that's the only mailing list which GvR follows apart from
python-dev. Any discussion here would likely have to be repeated over
there anyway, so why not go there earlier on?

Courtesy & respect on this and any list are important, so as long as
someone's not being genuinely rude or abusive, your best plan is to make
your point clearly and politely and then step back. I've been impressed
again and again on Python lists where people maintain a courteous front
in the course of a perhaps quite heated discussion. And more impressed
when people who have lost their cool come back and apologise (without
necessarily backing down from their point, of course).

Feel free to contact the list owner [python-list-owner@python.org] if
you think there's a real contravention of the list etiquette but I'm
personally not inclined to jump too heavily on rambling discussions or
wild-eyed ideas as such.

TJG

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

#106216

On Fri, 1 Apr 2016 07:27 pm, Tim Golden wrote:

> FWIW I'm broadly with Antoon here: wider-ranging discussions can be
> interesting and useful. 

Sure. But sometimes conversations are going nowhere:

http://www.youtube.com/watch?v=kQFKtI6gn9Y

http://www.montypython.net/scripts/argument.php


[...]
> If it becomes clear that the poster is in fact pushing for a change
> (either intelligently thought-out or naively ill-considered) then I
> would push them towards Python-ideas sooner than later, because that's
> exactly the purpose of *that* mailing list. People on python-ideas want
> to go to and fro over the relative merits of proposals. Specifically, I
> believe that's the only mailing list which GvR follows apart from
> python-dev. Any discussion here would likely have to be repeated over
> there anyway, so why not go there earlier on?

Informally, ideas are supposed to have an initial "sanity check" here to
avoid the really silly ideas:


Q: "Suggestion: I'm sick of writing

for key, value in other_dict.items():
    mydict[key] = value

I think that dicts should have a method to copy all the keys and values from
another dict."

A: "You mean dict.update?"


Or perhaps:

Q: "I think that object oriented programming is too inefficient. I think
that Python should get rid of all the objects and just be a lightweight,
easy-to-read wrapper around C, with the same semantics and limitations as
the 1988 C standard."

A: "Surely you aren't serious?"


But most people don't bother passing ideas through here first, they just go
straight to Python-Ideas.




-- 
Steven

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

#106217

Steven D'Aprano <steve@pearwood.info>:

> On Fri, 1 Apr 2016 07:27 pm, Tim Golden wrote:
>
>> FWIW I'm broadly with Antoon here: wider-ranging discussions can be
>> interesting and useful. 
>
> Sure. But sometimes conversations are going nowhere:

That's why GNUS has the "k" command to wipe out a whole thread.

I know, it depends on threading working...


Marko

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

#106231

On Friday, April 1, 2016 at 1:58:29 PM UTC+5:30, Tim Golden wrote:
> 
> For the latter, I take the view that I know where the delete key is (or
> the "ignore thread" button or whatever) and I just skip the thread when
> it shows up.

<snip>

> Feel free to contact the list owner [python list-owner] if
> you think there's a real contravention of the list etiquette but I'm
> personally not inclined to jump too heavily on rambling discussions or
> wild-eyed ideas as such.

I thought sanity was frowned upon out here <April-1-wink>

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

#106213

On 01/04/2016 08:59, Antoon Pardon wrote:
> Op 31-03-16 om 16:12 schreef Mark Lawrence via Python-list:
>> On 31/03/2016 14:27, Random832 wrote:
>>> 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?
>>>
>>
>> We can discuss anything here until the cows come home, but it's a
>> complete waste of time if the powers that be over on python-ideas
>> and/or python-dev don't agree.  This was suggested a day or two back
>> but seems to have gone completely over people's heads.
>
> Just because you are not interested, doesn't mean it's a complete waste of time.
> Discussions like this often enough produce suggestions on how one could handle
> these things within python without the need for the powers that be to agree on
> anything.
>
> If you are not interested just don't contribute. Others can make up their own
> mind on whether this is a waste of their time or not.
>

Who said I'm not interested?  It is a simple fact of life in Python 
world that anything that gets discussed has to go through python-dev, 
and possibly python-ideas first.  You can spend years discussing 
anything you like here and get 100% agreement, but if the devlopers say 
no it does not happen.

I believe that this proposal is like trying to change the design of the 
Morris Minor and a McClaren Mercedes because they're both cars, so you 
can make them similar.

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

#106109

On 30 March 2016 at 02:55, Terry Reedy <tjreedy@udel.edu> wrote:
> To me [seq.items() and seq.keys()] are useless and confusing duplications since enumerate()(seq)
> and range(len(seq)) are quite different from dict.items and dict.keys.

It's true. Indeed IMHO it's enumerate() that will be a confusing duplication.


On 30 March 2016 at 02:55, Terry Reedy <tjreedy@udel.edu> wrote:
> At least in CPython, changing a dict disables view iterators.

OrderedDict does not.


On 30 March 2016 at 07:43, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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.


So you basically say "I expect to get the value x from key y". Let me
apply your point of view to lists. In lists, I expect to get the value
x from index y. If I insert an item in a position before index y, I
expect to get x at index y+1. But what if I write a class with a
method insertPlus() that sets None at y+1 and x at y+2? I can say it
does not violate the list contract, since you're extending the base
class and implementing a new method that is not present in base class.

If you extend a dict to act as a list, you're only adding
*constraints* to existing methods and adding new methods. You're not
completely change the existing ones, so the implementation is
perfectly valid.

Finally, let me quote the official docs:

A mapping object maps hashable values to arbitrary objects [...] A
dictionary’s keys are almost arbitrary values [...]
https://docs.python.org/3/library/stdtypes.html#dict

Mapping:A container object that supports arbitrary key lookups
https://docs.python.org/3/glossary.html#term-mapping

A sequence satisfies all these requirements, with the only exception
that keys are not arbitrary. But no one will tell you that a child
class that make a *restriction* over the original one will break
rules.

On 30 March 2016 at 17:56, Steven D'Aprano <steve@pearwood.info> wrote:
> If the OP wants to create his own "StrangeDict", which he himself described
> as "terrible", then he can do so. But to make all dicts and lists behave in
> this "terrible" and "strange" way is a terrible idea.

You did not understand well what I mean, my dear friend. I applied the
word "terrible" to my code, not to the concept. You've demonstrated
that a fair thinker, so do not fall in the temptation to play with
words.

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

#106111

On 30/03/2016 20:35, Marco Sulla via Python-list wrote:
> On 30 March 2016 at 02:55, Terry Reedy <tjreedy@udel.edu> wrote:
>> To me [seq.items() and seq.keys()] are useless and confusing duplications since enumerate()(seq)
>> and range(len(seq)) are quite different from dict.items and dict.keys.
>
> It's true. Indeed IMHO it's enumerate() that will be a confusing duplication.
>

Please explain how a builtin that was brought in due to popular demand 
can be a "confusing duplication".

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

#106045

On 03/30/16 at 09:17pm, Steven D'Aprano wrote:
> On Wed, 30 Mar 2016 06:12 pm, Jussi Piitulainen wrote:
> 
> > Steven D'Aprano writes:
> > 
> >> Given a surjection (many-to-one mapping)
> > 
> > No. And I doubt that Wikipedia says that.
> 
> 
> No to what? What are you disagreeing with?
> 

I think it's with your definition of surjection. Bijections are
surjective, no?

Manolo

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

#106047

Manolo Martínez writes:

> On 03/30/16 at 09:17pm, Steven D'Aprano wrote:
>> On Wed, 30 Mar 2016 06:12 pm, Jussi Piitulainen wrote:
>> 
>> > Steven D'Aprano writes:
>> > 
>> >> Given a surjection (many-to-one mapping)
>> > 
>> > No. And I doubt that Wikipedia says that.
>> 
>> 
>> No to what? What are you disagreeing with?
>> 
>
> I think it's with your definition of surjection. Bijections are
> surjective, no?

Yes, and most many-to-one mappings are *not* surjective.

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

#106048

On 03/30/16 at 01:40pm, Jussi Piitulainen wrote:
> Manolo Martínez writes:
 >
> > I think it's with your definition of surjection. Bijections are
> > surjective, no?
> 
> Yes, and most many-to-one mappings are *not* surjective.

Well, I don't know about most, there are uncountably many surjective and
non-surjective many-to-one mappings :)

M

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

#106051

Manolo Martínez writes:

> On 03/30/16 at 01:40pm, Jussi Piitulainen wrote:
>> Manolo Martínez writes:
>  >
>> > I think it's with your definition of surjection. Bijections are
>> > surjective, no?
>> 
>> Yes, and most many-to-one mappings are *not* surjective.
>
> Well, I don't know about most, there are uncountably many surjective
> and non-surjective many-to-one mappings :)

Ok, safer to say that some many-to-one mappings are not surjective.

I was thinking of finite sets, and not even really thinking. But even
with infinite domain and infinite codomain, there can be uncountably
many mappings without any of them being a surjection - just have the
codomain be a larger infinity.

It depends on the types. Which makes the concept not easily applicable
to Python data structures as such.

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

#106055

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

> Manolo Martínez writes:
>> On 03/30/16 at 01:40pm, Jussi Piitulainen wrote:
>>> Yes, and most many-to-one mappings are *not* surjective.
>>
>> Well, I don't know about most, there are uncountably many surjective
>> and non-surjective many-to-one mappings :)
>
> Ok, safer to say that some many-to-one mappings are not surjective.
>
> I was thinking of finite sets, and not even really thinking. But even
> with infinite domain and infinite codomain, there can be uncountably
> many mappings without any of them being a surjection - just have the
> codomain be a larger infinity.

I don't even know if you can say much about the cardinality (or
countability) of mappings. The general set of mappings can't exist. The
*class* of mappings does exist in some set theories, but I don't believe
classes have cardinality.


Marko

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

#106058

On 03/30/16 at 02:44pm, Marko Rauhamaa wrote:
> Jussi Piitulainen <jussi.piitulainen@helsinki.fi>:
> 
> > Manolo Martínez writes:
> >> On 03/30/16 at 01:40pm, Jussi Piitulainen wrote:
> >>> Yes, and most many-to-one mappings are *not* surjective.
> >>
> >> Well, I don't know about most, there are uncountably many surjective
> >> and non-surjective many-to-one mappings :)
> >
> > Ok, safer to say that some many-to-one mappings are not surjective.
> >
> > I was thinking of finite sets, and not even really thinking. But even
> > with infinite domain and infinite codomain, there can be uncountably
> > many mappings without any of them being a surjection - just have the
> > codomain be a larger infinity.
> 
> I don't even know if you can say much about the cardinality (or
> countability) of mappings. The general set of mappings can't exist. The
> *class* of mappings does exist in some set theories, but I don't believe
> classes have cardinality.
> 

I guess I was thinking of the cardinality of the set of tuples with
members of the domain in the first member and their image in the second.
Many of those sets will have a well defined cardinality (unless I'm
missing something, which is entirely possible).

Anyway, this is all terribly OT. Thanks for humoring me.

Manolo

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

#106063

Manolo Martínez <manolo@austrohungaro.com>:

> On 03/30/16 at 02:44pm, Marko Rauhamaa wrote:
>> I don't even know if you can say much about the cardinality (or
>> countability) of mappings. The general set of mappings can't exist.
>> The *class* of mappings does exist in some set theories, but I don't
>> believe classes have cardinality.
>
> I guess I was thinking of the cardinality of the set of tuples with
> members of the domain in the first member and their image in the
> second.

If you fix the domain and codomain, then we can discuss cardinality
again, but the answer depends on the domain and codomain. For example,
if the domain is the empty set, there exists precisely one function. And
if the codomain is the empty set as well, that function is a bijection.


Marko

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

#106070

On 03/30/16 at 03:55pm, Marko Rauhamaa wrote:
> Manolo Martínez <manolo@austrohungaro.com>:
> 
> > On 03/30/16 at 02:44pm, Marko Rauhamaa wrote:
> >> I don't even know if you can say much about the cardinality (or
> >> countability) of mappings. The general set of mappings can't exist.
> >> The *class* of mappings does exist in some set theories, but I don't
> >> believe classes have cardinality.
> >
> > I guess I was thinking of the cardinality of the set of tuples with
> > members of the domain in the first member and their image in the
> > second.
> 
> If you fix the domain and codomain, then we can discuss cardinality
> again, but the answer depends on the domain and codomain. For example,
> if the domain is the empty set, there exists precisely one function. And
> if the codomain is the empty set as well, that function is a bijection.

Yeah, what I said and you quote above is wrong: I was thinking of the
cardinality of the set of those sets of tuples. This seems like the kind
of thing that would result in set-theoretic paradoxes, so yes, you are
probably right that the cardinality of mappings is not well defined.

Manolo

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

#106057

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?

Or an example of something which obeys the Mapping ABC which is not
surjective?

Artificial and contrived examples such as this do not count:

class MyDict(dict):
    def values(self):
        for value in super().values():
            yield value
        yield object()  # It's a value without a key!




-- 
Steven

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

#106059

Steven D'Aprano <steve@pearwood.info>:

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

Depends on the codomain. The values() method gives the range.

If you have an ordinary Python dictionary that maps strings to strings,
it will be neither total nor surjective. Since there are strings that
are not among the keys (not total) and there are strings that are not
among the values (not surjective).

You can of course equate keys() with the domain and values() with the
range, in which case the whole discussion becomes nonsensical.

However, a collections.defaultdict instance can be both total and
surjective in the meaningful senses of the words.


Marko

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

#106078

Marko Rauhamaa writes:

> Steven D'Aprano:
>
>> 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?
>
> Depends on the codomain. The values() method gives the range.
>
> If you have an ordinary Python dictionary that maps strings to strings,
> it will be neither total nor surjective. Since there are strings that
> are not among the keys (not total) and there are strings that are not
> among the values (not surjective).
>
> You can of course equate keys() with the domain and values() with the
> range, in which case the whole discussion becomes nonsensical.
>
> However, a collections.defaultdict instance can be both total and
> surjective in the meaningful senses of the words.

The cited Wikipedia article uses "image" for what Marko here calls
"range" (unfortunately it also calls individual values "images" (and the
elements of the domain and codomain, "expressions"), and "range" is also
sometimes used to mean codomain :).

I'm just pointing this out because range aka image is a key concept
here, together with codomain.

<https://en.wikipedia.org/wiki/Bijection,_injection_and_surjection>

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

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

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

csiph-web