Fredrik Johansson wrote:
> Python's current numeric model has serious problems.
Some of us (including myself) probably need enlightenment first:
what are the serious problems specifically?
> It's fine for
> calculating with nothing but floats, or nothing but ints, but writing
> code that works fo
Greg Ewing wrote:
>> If the implication here is that there is *no* GUI in the Python
>> standard library, I'd be cautious of this (-0, probably). Things like
>> the pydoc server use a little GUI window.
>
> There *isn't* currently any GUI in the core distribution
> except on Windows. Non-Windows u
On 5/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It's fine for
> > calculating with nothing but floats, or nothing but ints, but writing
> > code that works for ints, floats, complexes *and* Decimals - let alone
> > for custom types such as mpfs or numeric arrays - is nearly
> > impossi
One way of thinking about generic functions is that they are the dynamic
languages' equivalent to C++ function overloading. Now, there are lots
of valid (and some not-so-valid) use cases for function overloading; I'm
just going to pick one of the most common ones.
Many GUI libraries have the co
Talin wrote:
> One way of thinking about generic functions is that they are the dynamic
> languages' equivalent to C++ function overloading. Now, there are lots
> of valid (and some not-so-valid) use cases for function overloading; I'm
> just going to pick one of the most common ones.
>
> Many
Fredrik Johansson wrote:
> For example, square roots are known as math.sqrt(x) for floats,
> cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
> sqrt function that works on arrays (but not Decimals or gmpy's types)
Edward Loper wrote:
> (Note, this is not an argument against generic functions, which I think
> definitely have their uses; just an argument that this isn't a use case
> where I would choose to use them.)
Agreed - the use cases I see for function overloading in Python are more in
the domain whe
Martin v. Löwis wrote:
> Or, perhaps, you are talking about the binary distributions
> available from python.org? All binary distributions do include
> Tkinter, including the Linux RPMs:
My point was that not all platforms either come
with Tk installed or have Tk in the Python binary
installer, s
Talin wrote:
> r = Rectangle( x, y, w, h )
> r = Rectangle( minpos, maxpos )
> r = Rectangle( position, size )
This sort of thing is better done in Python using
keyword arguments:
Rectangle(left = x, top = y, width = w, height = h)
Rectangle(topleft = (x, y), size = (w,h))
Nick Coghlan wrote:
> Py3k's function overloading should fix this:
People are starting to talk about "Py3k's function overloading"
as though it were a done deal. Has anything actually been
decided about it yet.
--
Greg
___
Python-3000 mailing list
Pyth
Fredrik Johansson wrote:
> For example, square roots are known as math.sqrt(x) for floats,
> cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
> sqrt function that works on arrays (but not Decimals or gmpy's types)
On 5/12/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Both of these (return type annotation and selecting strict or lenient
> behaviour) can be done inline with the right methods on the annotation object.
[snip]
I've implemented this idea (a Function annotation, using Nick's
suggestion) in typech
Nick Coghlan wrote:
> Py3k's function overloading should fix this:
>
> @overloaded
> def sqrt(value):
> raise TypeError("Cannot take square root of %s" % type(value).__name__)
>
> @sqrt.overload
> def sqrt_float(value : float):
> return math.sqrt(value)
>
> @sqrt.overload
> def sqrt_comp
13 matches
Mail list logo
