Guido van Rossum wrote:
> On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
>> as specified in PEP 3100.
>
> Very cool! This is now checked in.
>
> Georg, can you do something about repr() of an empty set? This
> cu
Raymond Hettinger wrote:
> Georg Brandl wrote:
>
>>In the meantime, I played around with the peepholer and tried to copy
>>the "for x in tuple_or_list" optimization for sets. Results are in SF
>>patch #1548082.
>>
> Did you mean "if x in tuple_or_list"? IIRC, there was some reason that
> mutabl
Guido van Rossum wrote:
>> > However you might be able to just cleanup the grammar so they are
>> > identical, that would be simpler I suspect.
>>
>> Looking at the grammar, there's only testlist_safe left to kill, in
>> favor of or_test like in generator expressions. The old_ rules are still
>> n
On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >> > Georg, can you do something about repr() of an empty set? This
> >> > currently produces "{}" while it should produce "set()".
> >>
> >> Right, forgot about that case. I'll correct that now.
> >> (Grr, I even min
Georg Brandl wrote:
>In the meantime, I played around with the peepholer and tried to copy
>the "for x in tuple_or_list" optimization for sets. Results are in SF
>patch #1548082.
>
>
>
Did you mean "if x in tuple_or_list"? IIRC, there was some reason that
mutable lists were not supposed to be
Guido van Rossum wrote:
>> > Georg, can you do something about repr() of an empty set? This
>> > currently produces "{}" while it should produce "set()".
>>
>> Right, forgot about that case. I'll correct that now.
>> (Grr, I even mindlessly changed the unittest that would have caught it)
>
> Chec
On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> At python.org/sf/1547796, there is a preliminary patch for Py3k set
> >> literals
> >> as specified in PEP 3100.
> >
> > Very cool! This is now checked in.
>
>
Guido van Rossum wrote:
> On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
>> as specified in PEP 3100.
>
> Very cool! This is now checked in.
Wow, that's fast...
> Georg, can you do something about repr() of an e
On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
> as specified in PEP 3100.
Very cool! This is now checked in.
Georg, can you do something about repr() of an empty set? This
currently produces "{}" while it should
At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
as specified in PEP 3100.
Set comprehensions are not implemented.
have fun,
Georg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/p
On 8/8/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> I thought one of the main arguments in favor of set literals is that a
> literal form would allow the compiler to perform optimisations that
> the set(...) spelling doesn't allow.
Let me clear up this misunderstanding. Optimizations have nothin
> On 8/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > A different way to enable that would be to include a set of non-keyword
> > names
> > (a subset of the default builtin namespace) in the language definition that
> > the compiler is explicitly permitted to treat as constants if they are not
On 8/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Part 1: The concrete proposal part.
>
> I noticed that a lot of folks seemed to like the idea of making the
> empty set resemble the greek letter Phi, using a combination of
> parentheses and the vertical bar or forward slash character.
>
> So lets expa
On 8/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> A different way to enable that would be to include a set of non-keyword names
> (a subset of the default builtin namespace) in the language definition that
> the compiler is explicitly permitted to treat as constants if they are not
> otherwise d
Collin Winter wrote:
> On 8/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>> I personally don't see much of a use for set literals, considering that
>> there is a non-ambiguous spelling of it currently; set(...), whose only
>> cost above and beyond that of a set literal is a global name lookup.
"Collin Winter" <[EMAIL PROTECTED]> wrote:
>
> On 8/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I personally don't see much of a use for set literals, considering that
> > there is a non-ambiguous spelling of it currently; set(...), whose only
> > cost above and beyond that of a set liter
On 8/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> I personally don't see much of a use for set literals, considering that
> there is a non-ambiguous spelling of it currently; set(...), whose only
> cost above and beyond that of a set literal is a global name lookup.
I thought one of the main
Talin <[EMAIL PROTECTED]> wrote:
>
> Part 1: The concrete proposal part.
>
> I noticed that a lot of folks seemed to like the idea of making the
> empty set resemble the greek letter Phi, using a combination of
> parentheses and the vertical bar or forward slash character.
>
> So lets expand
Part 1: The concrete proposal part.
I noticed that a lot of folks seemed to like the idea of making the
empty set resemble the greek letter Phi, using a combination of
parentheses and the vertical bar or forward slash character.
So lets expand on this: slice Phi in half and say that (| and |) a
Raymond Hettinger wrote:
> I'm curious as to whether people will find one-type-with-two-purposes
> easier to learn that what we have now. My experience so far is that
> sets have a near zero learning curve as they are currently implemented.
And it's not just about ease of learning to use, b
On Mon, Jul 17, 2006 at 02:54:14PM -0700, Guido van Rossum wrote:
> Hm. Your objections seem to be purely from a performance tuning POV. I
> think that if we agree that API-wise this is an improvement (fewer
> things to learn, set literals problem solved, and dicts grow some
> useful new methods) w
On 7/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Hm. Your objections seem to be purely from a performance tuning POV. Ithink that if we agree that API-wise this is an improvement (fewerthings to learn, set literals problem solved, and dicts grow someuseful new methods) we should make a decis
Hm. Your objections seem to be purely from a performance tuning POV. I
think that if we agree that API-wise this is an improvement (fewer
things to learn, set literals problem solved, and dicts grow some
useful new methods) we should make a decision to do it and damn the
tuning (I trust Raymond wil
Guido writes:
> I've also sometimes thought of unifying dicts and sets by implementing
> set operations on the keys of dicts only.
[... much discussion ...]
> I'm still very much undecided but I don't want to rule this out for
> py3k. Perhaps I'll write up a PEP and see how it flies.
Playing w
> we haven't had that for long, and I cannot recall anyone being puzzled by the
> fact that you can use a dictionary of (item, None) pairs to efficiently
> represent
> a set.
message += " before set was added to the language"
___
Python-3000 maili
Greg Ewing wrote:
>> 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 of states from
> the NFA and associating each one with a state in
> the DFA.
>
> You can kludge around it, bu
Raymond Hettinger wrote:
> I'm curious as to whether people will find one-type-with-two-purposes
> easier to learn that what we have now.
we haven't had that for long, and I cannot recall anyone being puzzled by the
fact that you can use a dictionary of (item, None) pairs to efficiently
represen
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
> 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
Python-3000@python.org
http
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
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
Python-3000@python.org
ht
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
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:
> 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
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
While we're at it... what happens to frozenset?
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
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
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"
"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
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:
> # 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
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
Andrew Koenig wrote:
> Or you could adopt the approach used by SETL: A dict is equivalent to a set
> of 2-tuples.
>
> No, I'm not serious; I think it would be too big a change. But you have to
> admit it's a cool idea :-)
One fairly disastrous consequence would be that the *values*
would have t
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", 3: "d"}
# These already work:
> str and unicode are *distinct* types. they may be related, but not in
> the sense that type("hello") and type(r"hello") both return str.
They're distinct types, but not that distinct:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credi
> moreover, you can say a set is a "kind of" a keys-only dict. in fact,
> the first implementation of set used a dict, where the keys where the
> elements of the set, and their value was always True.
Or you could adopt the approach used by SETL: A dict is equivalent to a set
of 2-tuples. In other
-1.
On 7/7/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i had this idea -- since quoted literals can be prefixed by a letter
> that alters their meaning, why not use the same semantics
> with curly braces?
>
> "hello" -- byte string literal
> r"hello" -- unescaped byte string literal
> u"hello" -
str and unicode are *distinct* types. they may be related, but not in
the sense that type("hello") and type(r"hello") both return str.
moreover, you can say a set is a "kind of" a keys-only dict. in fact,
the first implementation of set used a dict, where the keys where the
elements of the set, an
> i had this idea -- since quoted literals can be prefixed by a letter
> that alters their meaning, why not use the same semantics
> with curly braces?
String literals are always strings, no matter what kind of string as
defined by the prefix. On the other hand, dictionaries and sets seems
differe
i had this idea -- since quoted literals can be prefixed by a letter
that alters their meaning, why not use the same semantics
with curly braces?
"hello" -- byte string literal
r"hello" -- unescaped byte string literal
u"hello" -- unicode string literal
{1:2, 3:4, 5:6} -- dict literal
s{1, 2, 3}
50 matches
Mail list logo
