Talin wrote:
> Ideally, if we get the signature API that's been discussed, then lists
> and tuples and such would have a constraint on their __getitem__ method:
>
> def __getitem__( self, index:int ):
>...
Don't forget those little beasties known as slices :)
Cheers,
Nick.
--
Nick
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote on 11/05/2006 17:18:39:
> At 04:27 PM 5/11/2006 +0100, [EMAIL PROTECTED] wrote:
> >Why not
> >
> >class Foo(object):
> > @specialize(arg(0))
> > def core.len(self)
> > ...
>
> Where does 'core' come from? What is speciali
well, i was aiming more to the point of having no types at all: only a
lookup chain for attributes (kinda like the mro), but being mutable.
an object in the lookup chain is any getattr-able object, and the
langauge takes care for it. for example, doing x.y means
* first look at the instance, if it
Collin Winter wrote:
> This exact thing (Function(type, type, ..., returns=type)) has been
> kicked around for inclusion in typecheck. One problem with using a
> keyword arg to indicate the return type means that functions passed in
> can't use that keyword argument themselves (unless you're not go
Talin <[EMAIL PROTECTED]> writes:
> For any two predicates A & B, comparing them will produce one of four
> possible outcomes:
>
> 1) A is a superset of B. In other words, any object that meets the
> criteria for B also meets the criteria for A.
> 2) B is a superset of A.
> 3) Neithe
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Talin wrote:
>> Ideally, if we get the signature API that's been discussed, then lists
>> and tuples and such would have a constraint on their __getitem__ method:
>>
>> def __getitem__( self, index:int ):
>>...
>
> Don't forget those little
I've now had time to have a play with this, and I've developed the
following implementation. It uses Guido's overloading module from his
blog.
It's quite similar to your proposal, but not as short as it uses current
python abilities. There's a little demo at the bottom.
Cheers,
Ben
from ov
On 5/11/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> IMO, the free mixing decimal and binary floats is not a good idea.
On 5/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Er, I thought Decimals were explicitly designed *not*
> to merge seamlessly with floats, so that one can't
> accidentall
At 10:14 PM 5/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>Marcin 'Qrczak' Kowalczyk wrote:
> > Talin <[EMAIL PROTECTED]> writes:
> >> # Use as a function argument constraint
> >> @generic
> >> def flatten( x:concepts.iterable ):
> >> ...
> >>
> >> # Another overload
> >> @generi
...
[Raymond Hettinger]
>> I write:
>>
>> if n&1:
>> handle_odd()
>> else:
>> handle_even()
>>
>> IMO, functions like is_even() and is_odd() are clutter. Also, the
>> performance of &1 is unlikely to be matched function calls.
[Fredrik Johansson]
> In your example, the problem is t
Tim Peters wrote:
> I do the same kind of thing all the time; e.g., here from the tail end
> of a hybrid modular/binary gcd function, which uses parity checks in
> three places:
>
> # invariants:
> # a > b >= 0
> # a is odd
> # b is odd or 0
> while b:
> a %= b
>
[Giovanni Bajo]
|> Since we're at it, do you have any idea on why Python is so slow when doing
> such bit-full code?
Is it, compared to the other interpreted languages? Doesn't look like
it. The cost of going around the eval loop once utterly swamps the
cost of doing a bitwise operation on nativ
On 5/12/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> What did he state twice? I see him checking the parity just once there.
The information "n is odd" appears once as "n&1" and once in the name
of a function. The point is that any if statement has the following
form:
if conditionX:
c
A quick disclaimer first: I'm not necessarily supporting Talin's proposal,
because I don't entirely understand it, and I think it's more ambitious in
scope and more vague in implementation details than what I'm proposing. So
I think he's proposing a superset of what I propose, and thus I only
Tim Peters wrote:
> [Giovanni Bajo]
>>> Since we're at it, do you have any idea on why Python is so slow
>>> when doing such bit-full code?
>
> Is it, compared to the other interpreted languages? Doesn't look like
> it.
Well, it seems like one of the few area where Python is slower than other
sc
Travis E. Oliphant wrote:
> Greg Ewing wrote:
>> Travis E. Oliphant wrote:
>>> The only thing I would wish different is to get rid of the PyGTK
>>> dependency. I think PyGUI should be a wrapper directly on top of GNOME
>> Perhaps you have Gnome and Gtk confused? Gnome is the
>> desktop, Gtk is t
Antoine Pitrou wrote:
> Le jeudi 11 mai 2006 à 10:00 -0600, Travis E. Oliphant a écrit :
>> That sounds reasonable. As I said before, I like the idea of PyGUI.
>> My main consternation is wxWindows. I'm not a big fan of how wxPython
>> builds on top of wxWindows which builds on top of GTK whic
[Fredrik Johansson]
> The information "n is odd" appears once as "n&1" and once in the name
> of a function. The point is that any if statement has the following
> form:
>
> if conditionX:
> consequence of conditionX
>
> So the if statement *inevitably* references conditionX twice, alth
[Giovanni Bajo]
>>> Since we're at it, do you have any idea on why Python is so slow
>>> when doing such bit-full code?
[Tim Peters]
>> Is it, compared to the other interpreted languages? Doesn't look like it.
[Giovanni]
> Well, it seems like one of the few area where Python is slower than other
19 matches
Mail list logo
