Hm. The double colon rubs me the wrong way (Perl and/or C++). But
apart from that, if this is the solution, I'm not sure the problem
you're trying to solve is really worth solving. I just don't expect
there will be all that many generic operations that need to be stuffed
into arbitrary classes. May
On 11/24/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2006, at 8:30 AM, Guido van Rossum wrote:
> > (It does imply that we can't use "-> None" to indicate "returns no
> > value". We'd have to spell that as "-> type(None)" or find some other
> > way. I think I don't care. Do others? Colli
On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Not sure I like this better. My spelling of "operator::XXX" is
> > > "__XXX__" and I like that just fine -- no new sy
> Obviously signature objects would grow support for annotations, but I
> still need the information to be carried on the code object to
> incorporate into signature objects.
>
Signature objects still need a way to know the nested parameters, right?
How about a co_argnames attribute? eg for
def f
[With apologies for having a monologue with myself here.]
On 11/24/06, I wrote:
> I'd like to take the opportunity to present another example of what
> I'd like to be able to do with abilities and generic functions.
[...]
Thinking about my own example some more, I think it would actually
work jus
On 11/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> tomer filiba wrote:
>
> > back in the day, we said all stream objects would support read() and
> > write(), and streams with limited functionality (readonly, writeonly) would
> > be "queriable" using the following properties:
> > * writable
> > *
tomer filiba wrote:
> back in the day, we said all stream objects would support read() and
> write(), and streams with limited functionality (readonly, writeonly) would
> be "queriable" using the following properties:
> * writable
> * readable
> * seekable
Is that really necessary? I can't rememb
Andrew Koenig wrote:
> def foo(a: T1) -> T2:
>
> I am presumably going to accept an argument of type T1 or a type derived
> from T1,
You're making assumptions about the semantics of the
annotations here, which I thought wasn't going to be
done.
--
Greg
_
class Interface(object):
""" A hashable, type-identifiable 'list'
The list should contain only other Interface objects
, Classes/Types, or Class Methods/Attributes, and strings
Interface objects can be used in specifying dispatch rules
and function
> Hm, I think it would be fine if there *was* no distinction. IOW if
>
> def foo(a: None) -> None: pass
>
> was indistinguishable from
>
> def foo(a): pass
>
> In fact I think I'd prefer it that way. Having an explicit way to say
> "no type here, move along" sounds fine.
I'd like to urge again
On 11/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/24/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 11/23/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > > > I have a working optional argument syntax implementation, I'm
> f.func_annotations
>> {'x': 1}
>
> Very cool! I agree that Phillip's idea for simplification is worth a
> try. We're generally not too concerned over the cost of function
> declarations since they typically execute only once per program. As
> long as it's really cheap when no annotations are
On Nov 24, 2006, at 8:30 AM, Guido van Rossum wrote:
>> I would rather see it integrated into a Signature object (Brett
>> had an
>> implementation), instead of showing up as two separate attributes.
>
> Yes, you're right; I forgot about that.
>
I'd imagine that the Signature object would live
> I believe this example captures an important requirement that has been
> expressed both by Bill Janssen and by Andrew Koenig (needless to say I
> agree): abilities should be able to imply contracts that go beyond a
> collection of methods (without necessarily being able to express those
> contrac
I'd like to take the opportunity to present another example of what
I'd like to be able to do with abilities and generic functions. It's
short on implementation and I don't want to emphasize syntax, but it's
high on concepts. The baseline assumption is that most built-in
operations, especially bina
On 11/24/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 11/23/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > > I have a working optional argument syntax implementation, I'm hoping
> > > to get some direction on
> > > the implementation de
recap: we agreed py3k needs a unified, better organized and unbuffered new
io stack. i began working on the subject several months back, and we had
long discussions on what it's design.
you can see where we got at the following page (although not up to date):
http://sebulba.wikispaces.com/project+
on 11/24/2006 12:34 AM Guido van Rossum wrote:
> I would like to end up in a world where, in order to claim that a
> class is a standard mapping class, the class definition would
> (normally) explicitly claim to implement StandardMapping (using as yet
> unspecified syntax)
Guido,
In my world
htt
> Let's see your implementation. Zope's interface system fails on at
> least points 3 and 5. And regarding #1, Zope's implementation of the
> basic features I described is an order of magnitude more complex, even
> if you compare *just* its code that implements adaptation and
> interface inherita
On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/23/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > I have a working optional argument syntax implementation, I'm hoping
> > to get some direction on
> > the implementation decisions so far please see below.
I would rather see it i
20 matches
Mail list logo
