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 whole thread.
I know,
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 wit
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
>>> thin
> 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 theoret
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 quite the same, but nicely found
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 could compose a table of c
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 actual
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.
The general need
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 ha
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 tha
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
bogoex
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 immutable keys rather than
inte
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 thread has had nothing but toy
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
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
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 Rossu
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 discussing by actually giving us an example that we can
>> discuss.
>
> S
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 most of the arguments here, but if you are talking
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 toy program, where it
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
> deleting one key will
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 is sit back and
>> wait as this
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 t
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 wan
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
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
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"
> directory["mary.address"
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"
Since Bob and Mary are
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.
>
> Re
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 m
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.
It's true. Indeed IMHO
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
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 confusing duplication
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 val
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 v
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 wit
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 giv
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
rep
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 *class* of mappings does exis
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 doubt
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 don't
>> believe classes hav
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 i
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 ord
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
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 uncountably many surjective
> >>
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 many-to-one mappings :)
>
> Ok, safer to s
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, th
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.
>>> N
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 a
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 disagreein
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
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 mappi
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 ab
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 that
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] == 456
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* stability;
>> if one item is at a lower index t
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 enumerate()(
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, until you change o
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 the value by re-assignment:
>>
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 between
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 for
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 vdi
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
ma
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 g
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 by
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 generic
> 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 *very
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 nee
82 matches
Mail list logo
