Steven Bethard wrote:
>
> 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? Sure, I can figure out what ``dict[str,
> str|int]`` means, but I still have no idea what you'd gain b
"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? Sure, I can figure out what ``dict[str,
> str|int]`` means, but I still have no i
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 tuple of two ints as tuple[int, int]
>
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> As a quick data point, I showed around your "dict[str, str|int]"
> example to some friends, all of whom have done a decent amount of
> coding in Python. I gave them some background, including that this was
> an example of type parameterization.
Collin Winter wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>>On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
>>
>>>As a quick data point, I showed around your "dict[str, str|int]"
>>>example to some friends, all of whom have done a decent amount of
>>>coding in Python. I
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Let's go back to Function(, , ..., returns=)
>
> I just finished converting typecheck's test suite to use this
> notation, and I have the following to report: ick.
>
> The main problem is
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> Let's go back to Function(, , ..., returns=)
I just finished converting typecheck's test suite to use this
notation, and I have the following to report: ick.
The main problem is when the function returns a complex type:
>>> Function(int, int
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > As a quick data point, I showed around your "dict[str, str|int]"
> > example to some friends, all of whom have done a decent amount of
> > coding in Python. I gave them some background
On 5/19/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> "Jim Jewett" <[EMAIL PROTECTED]> writes:
>
> > __getitem__ on a dictionary instance happens to be defined.
> > __getitem__ on the dict class happens not to be defined.
>
> I wouldn't be so sure.
>
> >>> dict.__getitem__
>
> >>> dic
"Jim Jewett" <[EMAIL PROTECTED]> writes:
> __getitem__ on a dictionary instance happens to be defined.
> __getitem__ on the dict class happens not to be defined.
I wouldn't be so sure.
>>> dict.__getitem__
>>> dict.__getitem__({'one':1}, 'one')
1
--
__("< Marcin Kowalczyk
\__/
On 5/19/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> On May 19, 2006, at 1:52 PM, Guido van Rossum wrote:
> >> Out of curiosity, are there concrete plans for how the type
> >> annotation syntax for functions
> >> translates into bytecode?
> >
> > I suspect rather similar to the way default parame
On May 19, 2006, at 1:52 PM, Guido van Rossum wrote:
>> Out of curiosity, are there concrete plans for how the type
>> annotation syntax for functions
>> translates into bytecode?
>
> I suspect rather similar to the way default parameter values are
> handled today: we generate bytecode that evalua
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > Use of positional arguments to parameterize dict, e.g., dict[str,
> > > Number], is ugly, but keyword arguments would allow t
On May 19, 2006, at 1:51 PM, Collin Winter wrote:
> On 5/19/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
>> I've been hacking on such a system, called "t_types". It is in pre-
>> release form right now.
>> It actually deduces type usage using bytecode simulation, before run-
>> time.
>
> What do yo
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(dict, object)
True
How can t
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm unconvinced. Can you provide an example of where this would be
> useful? I'm not looking for an example showing how it works; I want to
> see an example showing why we need this functionality.
Honestly, I don't have one.
Let's go back
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Use of positional arguments to parameterize dict, e.g., dict[str,
> > Number], is ugly, but keyword arguments would allow the prettier
> > dict[key=str, value=Number] (which might also
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > dict(normal=check3)["normal"] is not the same as dict["normal"] --
>
> Yes, they are. They both call __getitem__.
>
> __getitem__ on a dictionary instance happens to be defined.
> __getitem
On 5/19/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> The proposals I've seen here for type annotation syntax seem very
> intentionally
> designed NOT to lock in any particular type system.
Right.
> So far nothing seems to preclude
> static type checking, at least the way t_types works. I hope th
On 5/19/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> I've been hacking on such a system, called "t_types". It is in pre-
> release form right now.
> It actually deduces type usage using bytecode simulation, before run-
> time.
What do you mean by "bytecode simulation" and "before runtime"?
Also,
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > (1) Just use a tuple, and put the smarts in your decorator if you
> > > need to actually do something with the information.
>
> > >
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> So the real question is how best to write "A callable with this
> signature". I do not think the right answer is an inline recreation.
> Compare to
>
> from inspect import signature as sig
>
> def button_pushed(button,
>
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > ... what do you think of ... having bracket-based parameterization be
> > > redirected a call to some double-underscore method
> >
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> I'll concede that callbacks aren't often invoked in the foo(4, 5, c=7)
> style (so requiring certain parameter names is off the table), but
> I'll in turn push back on varargs and varkw parameters.
>
> I see these as being genuinely useful in h
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I think trying to put compound types directly into the signature may
> > require a little too much magic, compared to either:
> > (1) Just use a tuple, and put the smarts in your decorato
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > ... what do you think of ... having bracket-based parameterization be
> > redirected a call to some double-underscore method
>
> It already is -- to __getitem__.
>
> Having it go to somethin
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> ... what do you think of ... having bracket-based parameterization be
> redirected a call to some double-underscore method
It already is -- to __getitem__.
Having it go to something else just because you're in a function
definition is asking
On May 19, 2006, at 9:14 AM, Paul Boddie wrote:
> Guido van Rossum wrote:
>>
>> I'm not convinced that we need all this for the likely intended use,
>> since static type checking isn't really high on the agenda anyway.
>
> I know I'll get into trouble for quoting this out of context, and I
> ac
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think it's overkill and still not enough. When I write "def foo(a,
> b=2): ..." all of the following call signatures are valid: foo(1),
> foo(a=1), foo(1, 2), foo(1, b=2), foo(a=1, b=2), foo(b=2, a=1). Do we
> really want a notation that
"Collin Winter" <[EMAIL PROTECTED]> writes:
> Since Python 3000 will support things like "ClassA | ClassB", would
> you claim that "ClassA |" isn't an error (albeit a syntax error
> instead of a call error)?
It's a syntax error of course. But ClassA|ClassA is not an error.
--
__("< M
On 5/19/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The rest is just an exercise in attempting to come up with a pragmatic
> > set of operators and conventions that some people might be using for
> > talking about types. This is the idea o
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The rest is just an exercise in attempting to come up with a pragmatic
> set of operators and conventions that some people might be using for
> talking about types. This is the idea of parameterizing types a la
> dict[str, int|str] (which I
On 5/19/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> "Collin Winter" <[EMAIL PROTECTED]> writes:
> > 2. Similarly, annotation classes might want to do more complex
> > parameter validation. Or(), for instance, might want to assert that it
> > needs at least two distinct parameters (th
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think it's overkill and still not enough. When I write "def foo(a,
> b=2): ..." all of the following call signatures are valid: foo(1),
> foo(a=1), foo(1, 2), foo(1, b=2), foo(a=1, b=2), foo(b=2, a=1). Do we
> really want a notation that l
"Collin Winter" <[EMAIL PROTECTED]> writes:
> 2. Similarly, annotation classes might want to do more complex
> parameter validation. Or(), for instance, might want to assert that it
> needs at least two distinct parameters (that is, Or(int, int, int)
> simplifies to Or(int), which makes no sense a
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It feels a little too general for my taste. Have you written a bunch
> of those __parameterize__ functions yet?
Some, yes:
1. There's an example of a typecheck-able binary tree in typecheck's
tests/test_examples [1] that supports parameter
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/18/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> > > I have a question to the audience. How do you represent higher order
> > > functions using this syntax?
> >
> > I think Collin
On 5/19/06, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >
> > I'm not convinced that we need all this for the likely intended use,
> > since static type checking isn't really high on the agenda anyway.
>
> I know I'll get into trouble for quoting this out of context, and I ac
On 5/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > That's not quite how I did it. list[int] should return another type,
> > not a list instance. Here's a minimal example of what I'm after (truly
> > minimal because it only allows a sin
Guido van Rossum wrote:
>
> I'm not convinced that we need all this for the likely intended use,
> since static type checking isn't really high on the agenda anyway.
I know I'll get into trouble for quoting this out of context, and I accept
that there's a difference between static typing and writ
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> > I have a question to the audience. How do you represent higher order
> > functions using this syntax?
>
> I think Collin and I both (independently) proposed the pragmatic
> Function(, ,
You're right, that is better - I should have thought of it.
Thanks,
Tom
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Guido van Rossum
Sent: 19 May 2006 16:03
To: Thomas Dunham
Cc: python-3000@python.org
Subject: Re: [Python-3000] Another overloaded
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> That's not quite how I did it. list[int] should return another type,
> not a list instance. Here's a minimal example of what I'm after (truly
> minimal because it only allows a single parameter named T):
[snip]
I agree that the act of para
A classic Python way of doing this would be to extract the type name
from the token and use that for dynamic dispatch on methods of the
builder. This is in a sense "better" because it isn't restricted to
types (could be used to implement HTTP GET/POST/PUT too). Example:
class TEXbuilder:
def con
At 10:17 PM 5/18/2006 -0700, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>But even so we'd have to solve the delayed-loading issue: you don't
>want "import gmath" to imply "import decimal, math, cmath, gnump" nor
>would you (ideally) have "import decimal" imply "import gmath". But if
>both are im
The slides are titled Multimethods, Pattern:Builder and Pattern:
Builder with Multimethods.
http://norvig.com/design-patterns/img025.htm to img027.htm.
Choosing the correct action always depends on two things: what you are
converting and what you are converting it to. If you use multiple
dispatc
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> But even so we'd have to solve the delayed-loading issue: you don't
> want "import gmath" to imply "import decimal, math, cmath, gnump" nor
> would you (ideally) have "import decimal" imply "import gmath". But if
> both are imported (in either order
Brett writes:> as specified in the PEP. But that does not stop someone from
overriding> BaseException in a subclass, as some built-ins do already.
So you can> easily add your filename attribute.::
>> def __init__(self, filename):> self.filename = filename> BaseException.__init__(self,
48 matches
Mail list logo
