On 2008-01-25, Steven Bethard wrote:
> On Jan 25, 2008 12:18 AM, Mark Summerfield <[EMAIL PROTECTED]> wrote:
> > On 2008-01-25, Guido van Rossum wrote:
> > > For the record, I'm thinking Raymond has won this argument fair and
> > > square, and I'm withdrawing my opposition.
> > >
> > > I hope it is
On Fri, Jan 25, 2008 at 09:29:49AM +, Mark Summerfield wrote:
> In 2 or 3 years from now Python 3 will be "Python" for most people
It depends on how much it breaks. If Python 3 breaks too much people may
find it is a completely new language and decide to switch to another
language instead o
Mark Summerfield wrote:
> Python 3 is going to break compatibility anyway. I thought one of the
> purposes of having a new major release was to allow for such changes.
Please stop the discussion! Guido already voted against it. I assume
most of the remaining core developers agree with me that thre
Dnia 25-01-2008, Pt o godzinie 07:18 +, Mark Summerfield pisze:
> If you're going to make the change, why not make things consistent:
How often do you need the empty frozenset (which will stay as such),
compared to an empty dict (which will probably get filled later)?
The real inconsistency
Raymond Hettinger wrote:
> P.S. A small side-benefit is it may put an end for interminable requests for
> a {:} or {/} notation for empty sets. There's not much need for a literal
> for a empty frozenset (use "not s" instead).
How about also removing the {} as an empty dictionary? Then bo
On Jan 25, 2008 4:58 PM, Ron Adam <[EMAIL PROTECTED]> wrote:
> How about also removing the {} as an empty dictionary? Then both
> dictionary and set literals will require at least one item to be valid.No
> confusion, and {} is not allowed because it's ambiguous (to users) as to
> weather it's a
> should the repr for a set be set({a, b, c})
> instead of set([a, b, c])?
FWIW, running eval() on the repr is slower and less memory efficient with curly
braces than with the square brackets.
Also, it may be easily misread as meaning: set([frozenset([a, b, c])]). If the
latter is intended, t
Guido van Rossum wrote:
> On Jan 25, 2008 10:01 AM, Leif Walsh <[EMAIL PROTECTED]> wrote:
>> On Jan 25, 2008 12:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>>> The pipe char is ambiguous because is no direction. It was suggested and
>>> rejected last year.
>> Out of almost-pure devil's advoc
On Jan 25, 2008 12:52 PM, Collin Winter <[EMAIL PROTECTED]> wrote:
>
> On Jan 24, 2008 10:40 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Jan 24, 2008 5:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > > Looking over the code base, frozensets are used rarely.
> > > > So I don't think t
On Jan 25, 2008 1:31 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
>
> I'm a -0.9 on this one. I really like that Python is powerful, but also a
> great pedagogical language.
>
> I don't like that whereas before you could teach someone {} creates a dict,
> but now you have to say {} creates a dic
> There are also « and », << and >> for those w/o UTF-8 support in their
> mail client. On my keyboard the characters are available under [alt gr]
> + y and x.
Not elegant. It should look pretty. Code should look the same in all
character encodings unless alternate codings for used for identifie
On Jan 25, 2008 10:01 AM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2008 12:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > The pipe char is ambiguous because is no direction. It was suggested and
> > rejected last year.
>
> Out of almost-pure devil's advocacy, has <> been consider
Leif Walsh wrote:
> Out of almost-pure devil's advocacy, has <> been considered? My first
> instinct is that it would be ambiguous with less-than/greater-than,
> but if someone can convince me otherwise, might it work? After all,
> it's the only other balanced pair of punctuation I see on my keyb
On Jan 25, 2008 10:15 AM, nathan binkert <[EMAIL PROTECTED]> wrote:
> > No, there are too many syntactic situations where this would make the
> > grammar ambiguous or tortuous. We don't want to move beyond LL(1).
> > (Apart from parsing indentation and nested parentheses, of course --
> > which act
Dj Gilcrease wrote:
> This probably will not go over well, but why not use the pipe
> character to define a frozenset?
>
> if urltxt in |'html', 'xml', 'php'|:
The pipe char is ambiguous because is no direction. It was suggested and
rejected last year.
Christian
Mark Summerfield wrote:
> On 2008-01-25, Guido van Rossum wrote:
>> For the record, I'm thinking Raymond has won this argument fair and
>> square, and I'm withdrawing my opposition.
>>
>> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
>> while {1} creates an *immutable* frozense
I'm a -0.9 on this one. I really like that Python is powerful, but also
a great pedagogical language.
I don't like that whereas before you could teach someone {} creates a
dict, but now you have to say {} creates a dict, if there are colons
inside, or it's empty, but otherwise creates a frozenset.
> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> while {1} creates an *immutable* frozenset. I still find this slightly
> inelegant. But the practicality of being able to treat set literals as
> compile-time constants wins me over.
Another point in favor of Raymond's suggest
On Jan 25, 2008 10:32 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Leif Walsh wrote:
> > Out of almost-pure devil's advocacy, has <> been considered? My first
> > instinct is that it would be ambiguous with less-than/greater-than,
> > but if someone can convince me otherwise, might it work?
On Jan 25, 2008 10:01 AM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2008 12:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > The pipe char is ambiguous because is no direction. It was suggested and
> > rejected last year.
>
> Out of almost-pure devil's advocacy, has <> been considere
On Jan 25, 2008 12:37 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> The pipe char is ambiguous because is no direction. It was suggested and
> rejected last year.
Out of almost-pure devil's advocacy, has <> been considered? My first
instinct is that it would be ambiguous with less-than/greate
Raymond Hettinger wrote:
> I think it would be more useful for the {e1, e2, e3} literal to be a
> frozenset instead of a set.
+1 from me
Christian
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
On Fri, Jan 25, 2008, Mark Summerfield wrote:
>
> Python 3 is going to break compatibility anyway. I thought one of the
> purposes of having a new major release was to allow for such changes.
>
> In 2 or 3 years from now Python 3 will be "Python" for most people, and
> confusing inconsistencies wo
On Jan 24, 2008, at 20:32, Guido van Rossum wrote:
> Some folks thought it would be cute to be able to write incomplete
> code like this:
>
> class C:
> def meth(self): ...
> ...
>
> and have it be syntactically correct.
I think it would be been nice if "..." raised an NotYetImplemented
exc
On Jan 24, 2008 8:12 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> while {1} creates an *immutable* frozenset. I still find this slightly
> inelegant. But the practicality of being able to treat set literals as
> compile-time
On Jan 25, 2008 7:47 AM, Gisle Aas <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008, at 20:32, Guido van Rossum wrote:
>
> > Some folks thought it would be cute to be able to write incomplete
> > code like this:
> >
> > class C:
> > def meth(self): ...
> > ...
> >
> > and have it be syntactically c
On Jan 24, 2008 10:40 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008 5:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > Looking over the code base, frozensets are used rarely.
> > > So I don't think this is warranted.
> >
> > There is no shortage for perfect use cases in the f
27 matches
Mail list logo
