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.
> Feel free to contact the list owner [python list-owner] if
>
Steven D'Aprano :
> 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
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
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
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
>>>
> On Mar 31, 2016, at 10:02 AM, Marko Rauhamaa 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/
--
https://mail.python.org/mailman/listinfo/python-list
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
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
Jussi Piitulainen :
> 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
Random832 :
> 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
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
Chris Angelico :
> 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.
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
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
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
On 31/03/2016 13:49, Marco Sulla via Python-list wrote:
On 31 March 2016 at 14:30, Mark Lawrence via Python-list
wrote:
Note that dict also supports
__getitem__() and __len__(), but is considered a mapping rather than a
sequence because the lookups use arbitrary
On Fri, Apr 1, 2016 at 12:08 AM, 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
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
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
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
On Thu, Mar 31, 2016 at 11:36 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
>> wrote:
>> Okay. I'll put a slightly different position: Prove that your proposal
>> is worth
Chris Angelico :
> On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
> 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
On 31/03/2016 12:58, Marco Sulla via Python-list wrote:
On 31 March 2016 at 04:40, Steven D'Aprano 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
On 31 March 2016 at 04:40, Steven D'Aprano 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
>
On Thu, Mar 31, 2016 at 10:22 PM, Antoon Pardon
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
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
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
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
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
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
On Thursday 31 March 2016 13:45, Paul Rubin wrote:
> Steven D'Aprano 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"
>
Steven D'Aprano 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"
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
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.
>
>
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
On 30/03/2016 20:35, Marco Sulla via Python-list wrote:
On 30 March 2016 at 02:55, Terry Reedy 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.
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
On 30 March 2016 at 02:55, Terry Reedy 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
Op 30-03-16 om 17:56 schreef Steven D'Aprano:
> On Thu, 31 Mar 2016 12:12 am, Antoon Pardon wrote:
>
>> Op 30-03-16 om 14:22 schreef Steven D'Aprano:
>
> [...]
>>> Why is a mapping (such as a dict) best described as a surjection?
>>> Consider:
>>>
>>> d = {1: None, 2: 'a', 3: 'b', 4: None}
>>>
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
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
On Thu, 31 Mar 2016 12:12 am, Antoon Pardon wrote:
> Op 30-03-16 om 14:22 schreef Steven D'Aprano:
[...]
>> Why is a mapping (such as a dict) best described as a surjection?
>> Consider:
>>
>> d = {1: None, 2: 'a', 3: 'b', 4: None}
>>
>>
>> Every key has exactly one value. There are no values
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
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
On 03/30/16 at 03:55pm, Marko Rauhamaa wrote:
> Manolo Martínez :
>
> > 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
Op 30-03-16 om 14:22 schreef Steven D'Aprano:
> On Wed, 30 Mar 2016 09:28 pm, Jussi Piitulainen wrote:
>
>> Steven D'Aprano writes:
>>
>>> 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
Manolo Martínez :
> 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
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
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
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
On 03/30/16 at 02:44pm, Marko Rauhamaa wrote:
> Jussi Piitulainen :
>
> > 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
On Wed, 30 Mar 2016 09:28 pm, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
>
>> 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
Jussi Piitulainen :
> 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
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,
Antoon Pardon writes:
> Op 30-03-16 om 12:28 schreef Jussi Piitulainen:
>> Steven D'Aprano writes:
>>
>>> 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.
>>>
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
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
Op 30-03-16 om 12:28 schreef Jussi Piitulainen:
> Steven D'Aprano writes:
>
>> 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
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
Steven D'Aprano writes:
> 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?
Surjection does not mean many-to-one
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?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
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
Steven D'Aprano writes:
> Given a surjection (many-to-one mapping)
No. And I doubt that Wikipedia says that.
--
https://mail.python.org/mailman/listinfo/python-list
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
On Wednesday 30 March 2016 16:43, Steven D'Aprano wrote:
> This is not an argument about dicts being mutable, because clearly they
> aren't.
Er, I meant *immutable*. Dicts aren't immutable.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday 30 March 2016 14:38, Random832 wrote:
> On Tue, Mar 29, 2016, at 20:56, Chris Angelico wrote:
>> The map contract is this:
>>
>> x = StrangeDict()
>> x[123] = 456
>> ...
>> assert x[123] == 456
>>
>> Your mapping does violate the map contract.
>
> So, you can put *anything* in
On Tue, Mar 29, 2016, at 20:56, Chris Angelico wrote:
> The map contract is this:
>
> x = StrangeDict()
> x[123] = 456
> ...
> assert x[123] == 456
>
> Your mapping does violate the map contract.
So, you can put *anything* in that "..."?
x = dict()
x[123] = 456
x[123] = 789
assert x[123] ==
On Wed, Mar 30, 2016 at 9:29 AM, Marco Sulla via Python-list
wrote:
> On 29 March 2016 at 16:31, Chris Angelico wrote:
>> But the definition of a sequence, and likewise the definition of a
>> mapping, goes deeper than that. A sequence has *relative*
On 3/29/2016 6:29 PM, 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))
To me they are useless and confusing duplications since
On 29 March 2016 at 16:31, Chris Angelico wrote:
> But the definition of a sequence, and likewise the definition of a
> mapping, goes deeper than that. A sequence has *relative* stability;
> if one item is at a lower index than another, it will continue to be
> at a lower index,
On Wed, Mar 30, 2016 at 1:08 AM, Antoon Pardon
wrote:
> Op 28-03-16 om 03:05 schreef Steven D'Aprano:
>> When you add a new key:value to a dict, the other key:value pairs don't
>> change. That is the whole point of a mapping! Of course you can
>> deliberately change
Op 28-03-16 om 03:05 schreef Steven D'Aprano:
> On Mon, 28 Mar 2016 05:01 am, Marco S. wrote:
>
>> Steven D'Aprano wrote:
>>
>>> The point you might have missed is that treating lists as if they were
>>> mappings violates at least one critical property of mappings: that the
>>> relationship
On Mon, 28 Mar 2016 05:01 am, Marco S. wrote:
> Steven D'Aprano wrote:
>
>> The point you might have missed is that treating lists as if they were
>> mappings violates at least one critical property of mappings: that the
>> relationship between keys and values are stable.
>
>
> This is true
On 27/03/2016 19:01, Marco S. via Python-list wrote:
Mark Lawrence wrote:
I cannot see this happening unless you provide a patch on the bug
tracker. However I suspect you can get the same thing by subclassing
dict. Why don't you try it and let us know how you get on?
The problem with a
Steven D'Aprano wrote:
> The point you might have missed is that treating lists as if they were
> mappings violates at least one critical property of mappings: that the
> relationship between keys and values are stable.
This is true for immutable maps, but for mutable ones, you can simply do
On Sat, 26 Mar 2016 11:18 am, Marco Sulla wrote:
>> That's a very superficial similarity: a list ['a', 'b', 'x', 'y'] is
>> something like a mapping {0: 'a', 1: 'b', 2: 'x', 3: 'y'}. Seems logical,
>> since in both cases we write collection[2] and get 'x' back.
Marco, it is considered polite to
On 26/03/2016 00:35, Marco Sulla wrote:
I'd like to see vdict implemented anyway. It can't break old code and add a
map type that has a common interface with sequences.
I cannot see this happening unless you provide a patch on the bug
tracker. However I suspect you can get the same thing
Peter Otten wrote:
>> I noticed that the sequence types does not have these methods that the
map
>> types has: get(), items(), keys(), values().
>> It could seem useless to have them for sequences, but I think it will
ease
>> the creation of functions and methods that allow you to input a
> That's a very superficial similarity: a list ['a', 'b', 'x', 'y'] is
> something like a mapping {0: 'a', 1: 'b', 2: 'x', 3: 'y'}. Seems logical,
> since in both cases we write collection[2] and get 'x' back.
>
> But think about it a bit more, and you will see that the behaviour is in
> fact
On Wed, 23 Mar 2016 06:54 am, Marco S. wrote:
> I noticed that the sequence types does not have these methods that the map
> types has: get(), items(), keys(), values().
>
> It could seem useless to have them for sequences,
That's putting it mildly.
> but I think it will ease
> the creation
Marco S. via Python-list wrote:
> I noticed that the sequence types does not have these methods that the map
> types has: get(), items(), keys(), values().
> It could seem useless to have them for sequences, but I think it will ease
> the creation of functions and methods that allow you to input
I noticed that the sequence types does not have these methods that the map
types has: get(), items(), keys(), values().
It could seem useless to have them for sequences, but I think it will ease
the creation of functions and methods that allow you to input a generic
iterable as parameter, but
82 matches
Mail list logo