Guido van Rossum wrote:
> I've also sometimes thought of unifying dicts and sets by implementing
> set operations on the keys of dicts only. When the values aren't the
> same, we could make an arbitrary decision e.g. the left operand wins.
If the right operand always won then a |= b would be equiv
Guido van Rossum:
> # We could use these equivalencies:
> assert {1} == {1: None} == set({1: "a"}) # I.e. canonical sets have
> all None values
An alternative canonical representation of a set as a dict could be a
dict d for which d[k] is k for k in d.keys().
Guido van Rossum:
> Also, sets wou
On 7/10/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I've also sometimes thought of unifying dicts and sets by implementing
> > set operations on the keys of dicts only. When the values aren't the
> > same, we could make an arbitrary decision e.g. the left operand wins.
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> > Unfortunately we couldn't redefine <=, <, >=, > to mean various
>> > subset/superset tests without backwards incompatibilities (but does
>> > anyone care?
>>
>> You mean those are defined *now*? I'm trying to figu
Guido van Rossum wrote:
>I've also sometimes thought of unifying dicts and sets by implementing
>set operations on the keys of dicts only. When the values aren't the
>same, we could make an arbitrary decision e.g. the left operand wins.
>You get quite far. E.g.
>
>a = {1: "a", 2: "b"}
>b = {1: "c"
On 7/10/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >I've also sometimes thought of unifying dicts and sets by implementing
> >set operations on the keys of dicts only. When the values aren't the
> >same, we could make an arbitrary decision e.g. the left operand w
Terry Reedy wrote:
> If only we could persuade them to drop the braces...
> though maybe embedded in html/xml is one place they are useful.
The braces wouldn't be a problem if the semantics were
close enough to permit automatic Python-->Javascript
conversion...
--
Greg
__
While we're at it... what happens to frozenset?
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Guido van Rossum wrote:
>>
>> The deeper problem is that decisions on which values to keep will
>> inevitability break set invariants (see a long list of these in
>> test.test_set.py):
>>
>>assert a|b == b|a, 'commutative property'
>>assert (a-b) | (a&b) | (b-a) == a|b, 'whole is the sum o
Raymond Hettinger wrote:
> There would be some implementation consequences in terms of speed and
> memory usage (we would lose the memory savings and some of the speed-ups
> gained in the Py2.5 implementation of sets).
Is that really necessary? Couldn't the keys and values be
kept in separate a
Diogo Kollross wrote:
> While we're at it... what happens to frozenset?
Probably it becomes an immutable subsclass of dict.
Then, since the word 'set' is now free, we can rename
the somewhat awkward-sounding 'frozenset' to 'set'.
There would then be a nice symmetry between list/tuple
and dict/s
Raymond Hettinger wrote:
> The outermost set coercion is not especially attractive or efficient.
> Since equality/inequality is an important set operation, we would likely
> need to add a method for equality testing that ignores dict values:
Or coerction to a set could return a "set view" that
On 7/10/06, Diogo Kollross <[EMAIL PROTECTED]> wrote:
> While we're at it... what happens to frozenset?
I say nuke it. Who needs it?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
[email protected]
ht
Guido van Rossum wrote:
> On 7/10/06, Diogo Kollross <[EMAIL PROTECTED]> wrote:
>
>>While we're at it... what happens to frozenset?
>
> I say nuke it. Who needs it?
There are algorithms which effectively involve a
mapping keyed by a set. E.g. converting an NFA
to a DFA requires building up sets
> I'm curious as to whether people will find one-type-with-two-purposes
> easier to learn that what we have now.
I see no problem with that. We already have
lists-that-can-work-as-stacks-or-queues.
___
Python-3000 mailing list
[email protected]
http
There would be some implementation consequences in terms of speed and
memory usage (we would lose the memory savings and some of the speed-ups
gained in the Py2.5 implementation of sets).
Is that really necessary? Couldn't the keys and values be
kept in separate arrays, an
Currently, this is valid:
a = {'a': 1, 'a': 2}
print a # {'a': 2}
I wonder if we shouldn't make this a run-time error instead. If people
agree, what should we do with
a = {'a': 1, 'a': 1}
??? In ABC, that's legal (and the first one is indeed an error; I took
a shortcut when I decided
On 7/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Currently, this is valid:
>
> a = {'a': 1, 'a': 2}
> print a # {'a': 2}
>
> I wonder if we shouldn't make this a run-time error instead.
If it's possible, definitely. That's gotta be a typo if it appears in
real code.
> If people
18 matches
Mail list logo
