Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Assume the following is true for a type annotation system:
>>(T,) is equivalent to tuple[T]
>>(T1, T2) is equivalent to tuple[T1, T2]
>>(T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>>
>> but how do I use this system to spell the type anno
Travis E. Oliphant wrote:
> Guido van Rossum wrote:
>> On 5/20/06, Talin <[EMAIL PROTECTED]> wrote:
>>> As far as how to pick the set of operators, well my notion on that was
>> I suggest you let this rest for now. We have plenty of existing
>> operators, and I'd rather wait for a more compelling r
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Assume the following is true for a type annotation system:
>(T,) is equivalent to tuple[T]
>(T1, T2) is equivalent to tuple[T1, T2]
>(T1, T2, T3) is equivalent to tuple[T1, T2, T3]
This is ambiguous: tuple[T1, T2] is the same as tuple[(T1, T2
Nick Coghlan wrote:
> Using '@' would now be fairly counterintuitive, given that symbol's
> association with decorators.
It would be very disappointing if @ were now considered
too "polluted" by association with decorators to be used
for anything else, since it would mean we have lost both
a pot
On 5/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I'm confused as to why nobody seems to have noticed my proposal or
> prototype. So far my speculation is that it's outside of most people's
> ability to perceive, because it moots all the things they're arguing
> about. That is, it makes eve
On 5/21/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:> We have plenty of existing operators, and I'd rather wait for a more compelling reason to
> add more.Resting is good.http://www.python.org/peps/pep-0211.htmlhttp://www.python.org/peps/pep-0225.html
"No no, 'e's not dead, 'e's, '
On 5/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Something I've occasionally wondered about is just what it is that makes
> operators so much more convenient than methods or builtin functions for some
> operations.
Lambert Meertens, ABC's primary author, once explained this to me in a
way tha
At 02:44 PM 5/21/2006 +0100, Paul Moore wrote:
>Maybe just having a single "blessed" implementation of a function
>overloading module in the stdlib (even in the 2.x series) would be the
>best place to start. With a bit more real-world experience, it would
>be easier to see if there was call for int
At 08:51 PM 5/20/2006 -0600, Steven Bethard wrote:
>I'd particularly be interested in an example where overloading
>implies() to do something other than issubclass comparisons solves a
>real problem.
The prototype overloads implies() to allow a generic function to imply any
type that can be passe
On 5/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Assume the following is true for a type annotation system:
>(T,) is equivalent to tuple[T]
>(T1, T2) is equivalent to tuple[T1, T2]
>(T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>
> This fits in with how tuples are typically inten
On 5/21/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Nick Coghlan <[EMAIL PROTECTED]> writes:
>
> > Assume the following is true for a type annotation system:
> >(T,) is equivalent to tuple[T]
> >(T1, T2) is equivalent to tuple[T1, T2]
> >(T1, T2, T3) is equivalent to tupl
On May 21, 2006, at 2:23 PM, Collin Winter wrote:
> This is something I've been meaning to bring up: if we're serious
> about the "tuples = fixed-length collections, lists = unknown-length
> collections" distinction, then the CPython core should switch over to
> this mindset as well.
Although list
"Collin Winter" <[EMAIL PROTECTED]> writes:
>> > Assume the following is true for a type annotation system:
>> >(T,) is equivalent to tuple[T]
>> >(T1, T2) is equivalent to tuple[T1, T2]
>> >(T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>>
>> This is ambiguous: tuple[T1, T2] is the s
On Sun, May 21, 2006, Collin Winter wrote:
>
> This is something I've been meaning to bring up: if we're serious
> about the "tuples = fixed-length collections, lists = unknown-length
> collections" distinction, then the CPython core should switch over to
> this mindset as well. The fact that Pytho
On 5/21/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, May 21, 2006, Collin Winter wrote:
> >
> > This is something I've been meaning to bring up: if we're serious
> > about the "tuples = fixed-length collections, lists = unknown-length
> > collections" distinction, then the CPython core should swit
On 5/21/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/21/06, Aahz <[EMAIL PROTECTED]> wrote:
> > On Sun, May 21, 2006, Collin Winter wrote:
> > >
> > > This is something I've been meaning to bring up: if we're serious
> > > about the "tuples = fixed-length collections, lists = unknown-length
16 matches
Mail list logo
