Guido van Rossum wrote:
> I guess by "algebraic types" you meant enumerated types?
An algebraic type is somewhat more than that -- think
of it as something like a tagged tuple.
A less degenerate example would be (using a more
Haskell-like syntax):
Tree t = Leaf t | Node (Tree t) (Tree t)
Th
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 annotation for a tuple of un
Travis E. Oliphant wrote:
> I'm sorry to interrupt the resting, but I just wanted to remind
> everybody that Numerical computing people would still like a way to
> distinguish between "element-by-element" multiplication and tensor
> contraction (matrix multiplication).
A while back, there was
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 reason to add
> more.
>
I'm
Collin Winter wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> OK; for the return value (only) the Function().returns()
>> notation does look fairly pretty.
>>
>> I presume that return(int, int) is the same as return((int, int))?
>
> It is.
>
>> Weren't we going to write a tupl
Guido van Rossum wrote:
> On 5/20/06, Collin Winter <[EMAIL PROTECTED]> wrote:
>> 3. What will annotations on *varargs and **varkw look like? My own
>> suggestion is that
>>
> def foo(a: , *varargs: , **varkw: )
>> is fully equivalent to -- and is indeed coerced to --
>>
> def foo(a: , *var
Jim Jewett wrote:
> If the implementation of [] ends up doing the moral equivalent of
>
> (self.__getitem__(arg) if not isintance(self, type) else
> self.__parameterization__(arg))
>
> then we're running into problems with
>
> If the implementation is hard to explain, it's a bad idea.
I
Jim Jewett wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
>> B.__parameterize__ will only be called in the case of B[x] (as opposed
>> to B()[x]).
>
> new-style classes (the ones sticking around for python 3) are also instances.
>
> >>> isinstance(dict, type) and isinstance(dic
At 12:36 AM 5/20/2006 -0600, "Steven Bethard" <[EMAIL PROTECTED]> wrote:
>On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I've already addressed Steve's other issues. The blogs have the use
> cases etc.
>
>I'm sorry, I guess I'm just dense, but here's the blogs I've read:
>
>http://ww
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
>> to come up with a list of general mathematical and logical concepts, and
>> see if any would be useful as operators. In other words, the placeholder
On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > I guess in the end, I'm still a little confused at why we're having a
> > syntax discussion now. If type annotations are just an extra
> > expression in a function definition, why do
On 5/20/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > I wandered around
> > http://oakwinter.com/code/typecheck/
> > but couldn't find any discussion about the implications of, say,
> > requring the type ``{str:Number}`` (which I assume
Talin <[EMAIL PROTECTED]> writes:
> (Now all I need is a friendly way to spell "Var('x')" and I'm all set.)
var.x
> Another question that springs to mind is, what about the converse
> operator, '<-', and what does it represent? (Besides meaning "less
> than the negative of", which is a troubling
On 5/20/06, Talin <[EMAIL PROTECTED]> wrote:
> As far as how to pick the set of operators, well my notion on that was
> to come up with a list of general mathematical and logical concepts, and
> see if any would be useful as operators. In other words, the placeholder
> operators would have general
On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > You may have read my prototypes, which dispatch on concrete types.
> > Phillip lets you dispatch on predicates like hasattr(x, 'append').
>
> I assume you mean this one:
> http://
Tony Lownds wrote:
>
> Paul Boddie wrote:
> >
> > What's the general opinion on systems which attempt to infer and
> > predict inappropriate type usage?
[...]
> > Couldn't such systems be a better aid to program reliability?
> > Would "optional" type declarations be relevant to the operation
> >
Guido van Rossum wrote:
> On 5/19/06, Talin <[EMAIL PROTECTED]> wrote:
>
>> Side note: I'm actually in favor of the idea of Python adding
>> syntactical support for operators that have no "built-in" definition.
>> The use case would be for classes that define new operators that don't
>> correspond
On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Collin Winter's is pretty real, and I believe one other person (Tony
> > Lownds?) has another.
>
> I wandered around
> http://oakwinter.com/code/typecheck/
> but couldn't find any
On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > And the only use-cases I could extract are:
[snip]
> > * function overloading[1]. I think Philip J. Eby had some interesting
> > thoughts here, but in all the prototypes, dispatching
"Steven Bethard" <[EMAIL PROTECTED]> writes:
> (1) there were very few real implementations of the ideas, and
> (2) where there was an implementation, it relied on concrete types
Common Lisp has:
- Classes ("concrete types"), with explicit subclassing,
not parametrized, defined strictly, used
On 5/20/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> How about just dict[str:int]?
A bit too clever, although it happens to work syntactically -- it
calls dict.__getitem__(slice(str, int)).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
On 5/20/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I've already addressed Steve's other issues. The blogs have the use cases
> > etc.
>
> I'm sorry, I guess I'm just dense, but here's the blogs I've read:
>
> http://www.artima.com/we
On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I've already addressed Steve's other issues. The blogs have the use cases etc.
I'm sorry, I guess I'm just dense, but here's the blogs I've read:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpos
On May 19, 2006, at 9:23 PM, Talin wrote:
>
> OK, try this on your friends and see what happens:
>
> dict[ str >> int ]
>
How about just dict[str:int]?
> Alternative suggestion: Define -> as an operator.
>
I like this idea!
-Tony
___
Python-30
Guido writes:
> You can then write a decorator that does something with these. Or you
> can just use them as documentation. The decorators don't have to do
> type checking; they can do whatever you like; that's why there is no
> semantic constraint on the type annotations.
well, if that's the case
On 5/20/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> Some things I still have listed as "outstanding issues" for the annotations
> PEP:
>
> 1. You mentioned in one blog post [1] that you wanted to have 'any'
> and 'nothing' types. Is this still something you want as built-ins, or
> should it be
Some things I still have listed as "outstanding issues" for the annotations PEP:
1. You mentioned in one blog post [1] that you wanted to have 'any'
and 'nothing' types. Is this still something you want as built-ins, or
should it be left up to the annotation-interpreting libraries to
provide these
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > I know the plural of "anecdote" isn't "data"; maybe c.l.p should be
> > polled on some of these things?
Please don't. It serves no purpose; just like in US politics, you'll
always find a pretty much 50/50 split for and against any proposal
On 5/20/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i've been crying about that for quite a long time, but it seems people failed
> to see
> my point: type checking, which is more easily enforced by type annotations,
> is bad.
Pleast stop panicking. You don't seem to understand the proposal.
>
On 5/19/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> "Steven Bethard" <[EMAIL PROTECTED]> writes:
>
> > Which brings me to my comment about the current discussion. Can't we
> > drop the syntax discussion for a while and have someone motivate it
> > with some use-cases first?
Read my
On 5/19/06, Talin <[EMAIL PROTECTED]> wrote:
> Side note: I'm actually in favor of the idea of Python adding
> syntactical support for operators that have no "built-in" definition.
> The use case would be for classes that define new operators that don't
> correspond to the semantics of any existing
On 5/20/06, Talin <[EMAIL PROTECTED]> wrote:
> Here's a list of use cases that I can think of:
[...]
Interesting. Can you elaborate one of these into a strawman example,
with code, that we can discuss? There are a number of issues I can
see, but it's too easy to be vague without a concrete exampl
i've been crying about that for quite a long time, but it seems people
failed to see
my point: type checking, which is more easily enforced by type annotations,
is bad.
and because it will have this nice (and pointless*) syntax, lots of
people will start
using them everywhere, and make projects li
33 matches
Mail list logo
